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

[Michael]

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?

Already been working on an article/tests and had contacted AMD... Article should be out soon.

[Kayote]

I imagine since this a security matter it's going to get backported to all the kernel versions. Please keep us updated Michael if these patches get backported to older kernel.

[Michael]

I imagine since this a security matter it's going to get backported to all the kernel versions. Please keep us updated Michael if these patches get backported to older kernel.

Check on the site in literally 5 minutes from now for latest article....

[Kayote]

Already been working on an article/tests and had contacted AMD... Article should be out soon.

kernel HEAD repos contains the patch, updating Tumbleweed right now.

https://build.opensuse.org/package/show/Kernel:HEAD/kernel-firmware

[IMG]https://build.opensuse.org/user/icon/tiwai?size=20[/IMG][URL="https://build.opensuse.org/user/show/tiwai"]Takashi Iwai (tiwai)[/URL] accepted [URL="https://build.opensuse.org/request/show/561654"]request 561654[/URL] about 10 hours ago (revision 189)  
 - Add microcode_amd_fam17h.bin (bsc#1068032 CVE-2017-5715)

[bridgman]

My understanding was that the "real" fixes for Spectre were going to involve compiler work and take a fair amount time.

This is probably the equivalent of parking a big piece of heavy construction equipment across the entrance at night while you work on building a proper gate. And yes, the usual piece of equipment used is a bulldozer but there's no intentional joke in there.

[Kayote]

oh man!! I have to update my lineage OS rom image ARM also affected.

[Kayote]

https://bugzilla.suse.com/show_bug.cgi?id=1068032

Suse knew this bug since 1st December.

[Kayote]

sorry some time before actually

2017-11-14 11:40 UTC by Marcus Meissner

[hansg]

1. trains branch predictor to enter an unsafe instruction (like an if guarded boundary check)

One thing that was unclear to me: can you do this from another process? Or does it have to be done inside the same process that's being attacked? How can you train the branch predictor for branches in another memory image?

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.

As I understood it, k is a value you define yourself, it's the value in memory at array+k that is the secret. However, how come process A can read from memory owned by process B? If the cache is returning a value from another process entirely, surely that means it's fatally broken? So how am I to understand this: something like this?

1. Application does a syscall.
2. The kernel gets partially swapped in, and tricked into speculatively executing some code path.
3. Some kernel memory ends up in cache.
4. The syscall returns.
5. Somehow the application manages to obtain the value from the cache, even though the underlying memory has changed by this time since the kernel has swapped out again.

Something like this? But this can't be right: if the cache leaks kernel memory like this you wouldn't need all sorts of tricks to get to it, since it would be available after any syscall... Also, surely the cache is aware that it needs flushing after step 4?

[cen1]

However, how come process A can read from memory owned by process B?

Because the if guard is skipped and you can do a buffer overflow read due to speculative execution.