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

[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.

[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.

[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.

[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

[discordian]

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.

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.

[Michael_S]

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'm an AMD fanboy, so I would be thrilled to see that once all security design flaws are patched AMD is close to Intel or beats them outright. But I'm going to wait and watch a bit more before declaring victory. It's possible AMD has another form of the same kind of flaw.

[alpha_one_x86]

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

[starshipeleven]

I'm sure people who understand CPU architecture much better than I do have already researched and commented on this, but I will ask anyway:

Could this mean some portion of Intel's performance advantage over AMD in single-threaded speeds came by cutting corners?

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

[oleid]

Im curious, how much performance loss spectre and meltdown fixes yield in total. Considering AMD is only partially affected, hopefully they implement a runtime detection for what is really needed, as already done for meltdown.

[Spazturtle]

I'm sure people who understand CPU architecture much better than I do have already researched and commented on this, but I will ask anyway:

Could this mean some portion of Intel's performance advantage over AMD in single-threaded speeds came by cutting corners?

The vast majority of IPC gains in the past 15 years have come from Branch Prediction and Speculative Execution. This bug has revealed that Intel's branch prediction and speculative execution is build upon a flawed foundation. It is possible that they were only able to reach the high IPC they did because the foundation was flawed and allowed certain things that shouldn't have been allowed. Intel won't be able to fix this until the 10000 series at earliest, so we will have to see how much of the work they have done over the past 10 years is salvageable and how much needs to be thrown away and re-built from the ground up like AMD did with ZEN.

This plus Intel's own admission that their 10nm node will be slower and have worse power efficiency then their existing 14nm node means Intel are going to have a rough time over the next few years, if I was a share holder I would be asking the board when they plan on firing Brian Krzanich.