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

[phoronix]

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

Besides the already-merged Kernel Page Table Isolation (KPTI) patches, other Linux kernel patches are coming out now in light of the recent Spectre and Meltdown vulnerabilities...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Kernel-Retpoline-Patches

[log0]

And here something for the popcorn crowd :P

On Wed, Jan 3, 2018 at 3:09 PM, Andi Kleen <[email protected]> wrote:
> This is a fix for Variant 2 in
> https://googleprojectzero.blogspot.c...with-side.html
>
> Any speculative indirect calls in the kernel can be tricked
> to execute any kernel code, which may allow side channel
> attacks that can leak arbitrary kernel data.

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

- Intel never intends to fix anything

OR

- these workarounds should have a way to disable them.

Which of the two is it?

Linus

[Michael_S]

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?

[cen1]

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.

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

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

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

[alpha_one_x86]

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

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

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