More Linux Kernel & GCC Patches Come Out In The Wake Of Spectre+Meltdown

[discordian]

And OpenRISC no is the best way to control the hardware layer to prevent this kind of problem?

Nope, pedantic design criteria (ie start wih knowing about these possibilities) and validation are the only way.

I would guess x86 is particularly handicapped because it uses a stubborn memory model where everything has to be visible to multiple separate paths (so 40 year old self-modifying code continues to run). Ie those speedups like speculation and branch-prediction come with a more complex hardware than elsewhere

[L_A_G]

there are enough rumours around since 2013 that their QA and testing was "sped up" for the sake of catching up more with ARM.

I would read too much into that seeing how this issue goes back to the original P6 architecture from the mid 90s and the rumors are based on a (since-deleted) anonymous post on Reddit.

[duby229]

Indeed, but it still is alot of guesswork if other threads (HW or Software) could interfere with the caches. The crazy thing is that alot of easily accessible and welcome dev features like perf-counters are now a double edged sword.
This is only the start of a paradigm shift, for me partly unwelcome as this turns alot assumptions upside-down but also party welcome as clean and virtualizable ISAs could get a foothold in x86 dominated areas

I had a discussion with a guy last year, about side-channels with network communication, this is on the same level.

Yes exactly. I can't say I understand what the current vulnerabilities really mean, but I can say for damn sure it doesn't seem at all like a bug. The behavior described seems like it's 100% completely designed exactly as intended. Perhaps it is a vulnerability after the fact of being discovered, but not a bug at all.

[discordian]

Yes exactly. I can't say I understand what the current vulnerabilities really mean, but I can say for damn sure it doesn't seem at all like a bug. The behavior described seems like it's 100% completely designed exactly as intended. Perhaps it is a vulnerability after the fact of being discovered, but not a bug at all.

Sorry, but no. This is heck of a bad backdoor if designed, and the implementation and it pitfalls make alot sense. Tapping sidechannels is only recently in focus, the effects of the new discoveries is what I meant with paradigm shift.

now you can expect an industry wide hunt for these issues no one cared about before.

i wonder if the end result will be that all measurement methods will be gimped to disallow finding short paths in the hardware.

[pixo]

I had fun time reading the papers. Basically, AFAIK, al CPUs that have speculative execution (all?) are susceptible to Spectre attack which is a cache timing attack. It is a bit hard to explain but basically does this:

Code sample from paper:
if (x < array1_size)
y = array2[array1[x] * 256];

k=array1[x]=secret value we want

1. trains branch predictor to enter an unsafe instruction (like an if guarded boundary check)
2. speculative execution will just start executing second row, affecting the cache in the process
3. now you essentially made a memory access on array2 using index k which is a secret. So now you simply loop read on the array2 and time the memory access, where it loads fastest a cached read was made and you found the k.

..something like that. It is kinda mind blowing.

This only allows you to read memory of the same process which is already problematic but Intel has an additional issue where it speculatively executes even memory reads which you shouldn't have access to while AMD doesn't. This second problem is called Meltdown and only affects Intel and I think some ARM processors.

I think this is Spectre v1 you are mentioning.
The patches are for Spectre v2.
AMD statement is that there is near zero risk for this to work on their CPUs.

It so confusing right now.
2 different sidechannel attacks are called spectre and one is called meltdown.
Intel tries to put them to one basket as they are affected by all 3. Nice PR move.
AMD claims they are affected only by Spectre v1, which seems to affect most, if not all, out-of-orded CPU architectures.

[ryszardzonk]

A quick question. If I apply all those patches for my system running on i7-6700K and I reboot my machine would it start up before the end of 2018?

[brrrrttttt]

Nope, pedantic design criteria (ie start wih knowing about these possibilities) and validation are the only way.

I would guess x86 is particularly handicapped because it uses a stubborn memory model where everything has to be visible to multiple separate paths (so 40 year old self-modifying code continues to run). Ie those speedups like speculation and branch-prediction come with a more complex hardware than elsewhere

Good argument in favour of Itanium?
I guess we can indirectly blame it all on AMD as they caused us to be stuck with x86! </sarcasm>

[M@yeulC]

A quick question. If I apply all those patches for my system running on i7-6700K and I reboot my machine would it start up before the end of 2018?

No, you need a patch to fix the y2k18 bug first.

I can't wait for some big RISC-V processors (or whatever, but challenge x86 a bit) in my system. As a plus, Open Source Software would be at an advantage here.

[Yndoendo]

We are more or less stuck with x86 not because of a well designed architecture but to allow the continual usage of old and new Closed Sourced software running.

Open source actually allows CPU jumping. Reason Linux runs on most processors.
Apple had to come-out with new OS that no longer runs all those old applications to jump to a different CPU.
Microsoft tried to accommodate a different CPU but no business really bought it since they need to keep running their Closed source packages.

https://www.youtube.com/watch?v=1FtEGIp3a_M has a good talk about hacks with-in x86.

[khnazile]

suse people rolled out some mysterious cpu firmware update that disables branch prediction for ryzen: https://lists.opensuse.org/opensuse-.../msg00000.html could someone tell me what is this about? Wouldn't complete disablement of branch prediction slow down my ryzen to AMD K6 performance levels?