Originally posted by khnazile
View Post
Announcement
Collapse
No announcement yet.
More Linux Kernel & GCC Patches Come Out In The Wake Of Spectre+Meltdown
Collapse
X
-
Michael Larabel
https://www.michaellarabel.com/
- Likes 2
-
Originally posted by Kayote View PostI 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 Larabel
https://www.michaellarabel.com/
Comment
-
Originally posted by Michael View Post
Already been working on an article/tests and had contacted AMD... Article should be out soon.
This package contains the firmware for in-kernel drivers that was previously included in the kernel. It is shared by all kernels >= 2.6.27-rc1.
Code:[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)
Comment
-
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.Last edited by bridgman; 04 January 2018, 10:25 PM.Test signature
- Likes 2
Comment
-
-
Originally posted by cen1 View Post1. trains branch predictor to enter an unsafe instruction (like an if guarded boundary check)
Originally posted by cen1 View Post2. 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.
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?
Comment
Comment