'Kernel memory leaking' Intel processor -- a serious cpu bug!?!

[EvilDragon]

Boy did I ROFL. They translated Intel's PR spin pretty well

[fluffy_little_something]

Glad a bought a Ryzen

[gnu23]

Intel's official statement about the issue.

El Reg translation of this:

https://www.theregister.co.uk/2018/01/0 ... notations/

*chuckle* El Reg hits it right on the nose.

Right now, it looks like VM's in cloud stacks (think AWS and Azure) are going to be where the greatest risks are and where the performance hit will be most keenly felt.

For what it's worth, VM's on a blade, sharing memory, have been a security concern for a long time. The part in the El Reg post that concerns me somewhat is that for folks like us, using software to make music, the hit will most likely be seen in disk calls.

There's still some noise around all of this. Speaking only for myself, I'll have to use my i5 for some years yet, so there's not much I can do about it.

[Chris-S]

Glad a bought a Ryzen

AMD is also affected AFAIK.

But as already has been said here, all is still speculation.

[EvilDragon]

AMD is affected by Spectre (and even that one in an extremely unlikely scenario), not Meltdown. Meltdown is Intel-specific (and ARM Cortex-A75). So, the performance decrease-inducing fix will not affect AMD (at least on Linux, we're waiting on W10 update benchmarks for AMD...).

[nIGhT-SoN]

My understanding from reading through that is that in the long term Spectre is a very big deal because it will require a completely new processor architecture to avoid it.

Both of them need architecture change, the only thing is Meltdown can be "fixed" through a patch, but that will lower performance. That can't be called an actual fix. The only way to truly fix that is through changes in the processor architecture. Also it's not a big deal because software can avoid it if done so, it's not a security flaw like Meltdown. Here is a description:

Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre

Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.

AMD has problems only with Specter variant 1 and 3, I think. Variant 1, I've read a comment on reddit, will probably be patched, that one might come with negligible performance impact.

[lnikj]

However, it is possible to prevent specific known exploits based on Spectre through software patches.

I read that as - once an an exploit is known then it can be patched; however, Spectre opens the door to exploits yet unknown.

I could be wrong though. Not an expert!

Edit: From the paper: https://spectreattack.com/spectre.pdf

"The feasibility of exploitation depends on a number of factors, including aspects of the victim CPU and software and the adversary’s ability to interact with the victim. While network-based attacks are conceivable, situations where an attacker can run code on the same CPU as the victim pose the primary risk. In these cases, exploitation may be straightforward, while other attacks may depend on minutiae such as choices made by the victim’s compiler in allocating registers and memory. Fuzzing tools can likely be adapted by adversaries to find vulner- abilities in current software."

Suggests to me that the number of exploits is currently indeterminate.

[bmrzycki]

Variant 1 and variant 2 can be patched with hardware updates in the micro-architecture. Variant 1 can be fixed by preventing the out-of-order engine from speculating across a permission fault. Variant 2 can be prevented by tagging the branch predictor with the exception level so that levels can’t influence each other. Variant 3 requires kernel software patches to employ a lightweight barrier instruction before switching between trusted and untrusted code (in syscalls typically).

Variant one is a small performance loss in that speculation is now a bit more pessimistic. Variant two only adds die memory to the TLB.

Variant three will add a bit of a performance hit to pessimize all out-of-order instructions between a user app into a syscall. It also requires either reusing an existing memory barrier instruction or extending the instruction of an ISA to add it. Not sure which will be done by x86_64 and Aarch64 respectively.

I expect the next round of AMD and Intel processors will champion their fixing of these problems. Until that happens I think I'll hold off on buying any new CPUs.

Finally, I suspect Google targeted Intel because that's the primary vendor they (and most of the cloud) deployed. I do agree that Intel's specuation is much more aggressive than AMDs but both of them have some aspect of the problem.

I expect at least one class-action lawsuit from companies like HP, IBM, or Dell to be filed against Intel in the wake of this, assuming Intel isn't quietly replacing cores for the big boys' customers...

[Zombie Queen]

There may be a lot of cheap but powerful second hand processors on the market, soon...

[rgarner]

I'm running MacOS 10.12.6, or Sierra (no High – I'm holding off due to that OS still settling down).

The patch for Sierra appears to have been released on 6th December. Look down to "Kernel" and you'll see a reference to Ian Beer of Google Project Zero.

I installed this patch on 23rd December, because I had a bit of time spare in the holidays. I was a bit shocked to see the two-reboot loop that usually indicates something firmware- or kernel-related.

I also bought Softube Volume 1 and got into Modular, which I thought was incredibly CPU heavy – suddenly I was having to boost my Logic Pro X I/O buffer size from 128 to 1024 to even run 3 or 4 of these plugins on a (bought earlier this year) top-of-the-line mid-2015 Macbook Pro with quad-core i7@2.8Ghz/16GB, and I'm frequently getting "couldn't process audio in time".

After hearing about Meltdown this morning, I went back to my previous mixes that have never had CPU problems and don't use Modular. Sure enough, I can't run any of them on the built-in outputs without having to whack the I/O buffer up, and that's often no longer enough.

So for me, the "hysteria" about this is entirely justified. Nothing else has changed, but my portable mixing experience away from the audio interface (I haven't yet tried it with the Clarett 4Pre it's usually hooked up to) is far, far worse since Christmas.

I'm speaking to AppleCare about what they might do to restore my performance.

[lalo]

https://forum.juce.com/t/how-does-the-i ... apps/25812

Some interesting things on this topic at juce forum...

[Daags]

anyone ever come across any stress test benchmarks of win7 vs win10 running on kabylake (i7 7700hq) ?

i know kabylake is not officially supported on win7, but there's ways of fooling win7 into thinking it is supported hardware. people are doing it, but i just can't find any benchmarks. i'm looking for benchmarks because i want to know just how true it is that kabylake 'runs better on win10 anyway' ... (which is a typical comment you come across when googling about installing win 7 on unsupported cpus, but i've never seen these comments substantiated with benchmarks so i wonder if they're just repeating pr bullshit)

[rsmus7]

here you find a bit more about the cpu bugs and solutions from the linux side:

https://lwn.net/Articles/738975/

While the patch does not mention it, one could imagine that, if the presence of the remaining information turns out to give away the game, it could probably be located separately from the rest of the kernel at its own randomized address.

The performance concerns that drove the use of a single set of page tables have not gone away, of course. More recent processors offer some help, though, in the form of process-context identifiers (PCIDs). These identifiers tag entries in the TLB; lookups in the TLB will only succeed if the associated PCID matches that of the thread running in the processor at the time. Use of PCIDs eliminates the need to flush the TLB at context switches; that reduces the cost of switching page tables during system calls considerably. Happily, the kernel got support for PCIDs during the 4.14 development cycle.

Even so, there will be a performance penalty to pay when KAISER is in use:

KAISER will affect performance for anything that does system calls or interrupts: everything. Just the new instructions (CR3 manipulation) add a few hundred cycles to a syscall or interrupt. Most workloads that we have run show single-digit regressions. 5% is a good round number for what is typical. The worst we have seen is a roughly 30% regression on a loopback networking test that did a ton of syscalls and context switches.

Not that long ago, a security-related patch with that kind of performance penalty would not have even been considered for mainline inclusion. Times have changed, though, and most developers have realized that a hardened kernel is no longer optional. Even so, there will be options to enable or disable KAISER, perhaps even at run time, for those who are unwilling to take the performance hit.

and the first lawyers start to investigate:

https://www.businesswire.com/news/home/ ... s-Howard-G

[dzilizzi]

Well, this really sucks. I break the hinge on my non-music laptop yesterday and then start seeing this. Not to mention all the good laptop sales are over. However, AMD laptops are cheaper. So not sure if I can wait until the newer Coffee Lake processors hit the laptop market at a reasonable price.

The way I see it, doesn't matter if you have AMD, because if the OS is issuing the fix, it will affect AMD processors the same as Intel. I can probably not do the update, since my music computer is running Windows 7 and I only go online to certain companies, like NI or Toontrack, to download and update products. But it is probably worth it to just be safe. Until we know how much damage a virus can do - i.e. if you keep backups and can just format and reload if it gets taken over, it is okay. But if it trashes your machine and wipes you out, not good. This is the problem though. The OS's will now always have to have that "fix" coded in whether your processor needs it or not. At least until they can assume no one is using those processors anymore.

And? If the CEO sold all his shares when he found out this information, I'm thinking jail time for insider trading......Or at least big fines.

[Jax Pok]

Got the update compared screen capture of I song I did before the update and the CPU Meter in Ableton is peeking at 72% instead of 67% Abletons CPU meter is a bit odd though it's not a proper CPU utilization meter but gives an idea of how a computer is managing running all the tracks.

Skylake X i9 7920x
RME Babyface Pro
Windows 10
Ableton lIve 10.
92khz 512 samples.