7 ms·

Looks like it is speculative execution based, and does not affect AMD https://lkml.org/lkml/2017/12/27/2 https://lkml.org/lkml/2017/12/27/2 AMD processors are

Looks like it is speculative execution based, and does not affect AMD https://lkml.org/lkml/2017/12/27/2 https://lkml.org/lkml/2017/12/27/2 AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault. Disable page table isolation by default on AMD processors by not setting the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI is set.

acoye 9y ago
Do you think this could be within the rather new Intel AVX 512 ISA or older intel CPUs like Sandy Bridge (first AVX chip) could also suffer? - edit - I checked Ryzen ISA, they support AVX2. So probably AVX512 is the issue.
- rphlx 9y ago
  It has nothing to do with AVX AFAICT. They are going to set X86_BUG_CPU_INSECURE [1] on all public Intel CPUs, including old ones that lack AVX (Core2, etc). [1] I do hope they rename that flag to something like X86_BUG_NEEDS_PTI as the current name is bloody abysmal: way too broad and ambiguous, as if this is the only insecurity that ever has or ever will impact x86.
  - wilun 9y ago
    Well that very name hints that it is probably a very annoying bug, with an impact way more annoying that a simple ASLR address leak or data access trace (hell, Intel does not even consider side-channel data access / tlb tracing to SGX a vuln, so this has to be better than that kind of issues...)
- fulafel 9y ago
  Everything so far hints at a microarchitecture bug, not a ISA specific.
wilun 9y ago
I guess Intel decided to speculate data access regardless of privilege level of the target address, with the theory that what has been successfully speculated can't be accessed anyway before the permission are really checked, and somebody found a bug (or given all Intel processors are taggued as unsecure, maybe a quasi-architectural hole) that let read the speculated data or a significant subset or trace of it. My wild guess is that you can read a good portion (if not all) of the memory (or a significant subset or trace of it) of the whole computer from unprivileged userspace programs.
- zimmerfrei 9y ago
  Could this be possibly fixed with a microcode update in the future (at least for most recent models for which Intel is still bound to some kind of warranty)?
  - justincormack 9y ago
    I think probably not, I think it may be too fundamental. But perhaps there is a mitigation if only a few instructions cause the leak and they can disable those in speculation. Performance hit could be bad though, worse than the Linux fix.
- rst 9y ago
  One possible vector suggested by Matt Tait (pwnallthethings) on Twitter: if speculative operations can influence what the processor does with the cache, the results can be observed with cache timing attacks. If the branch predictor reads the results of speculative operations, it's real easy, as he suggests here: https://twitter.com/pwnallthethings/status/947978927284383744 https://twitter.com/pwnallthethings/status/94797892728438374... but (as he notes elsewhere) there are plenty of other channels in an Intel processor for information to leak...
  - Taniwha 9y ago
    my guess is that the cache tags or tlb entries loaded on failed speculative accesses are wrong (maybe the valid bit is set but the address wasn't changed, or the user/supervisor protections are munged), that could leave you with a cache line or page tagged as user accessible but really protected kernel data
slackingoff2017 9y ago
maybe it has to do with CR3 register? https://patchwork.kernel.org/patch/10138835/ https://patchwork.kernel.org/patch/10138835/ Edit: switched to link without AD cancer
- bitexploder 9y ago
  I think they are just using the CR3 register to implement the fix. The actual side channel will be something a bit more esoteric. Something like this: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/ https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...
jedisct1 9y ago
They might have succeeded to make it work: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/ https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...
- Pyxl101 9y ago
  Previously posted on HN as well: https://news.ycombinator.com/item?id=14988157 https://news.ycombinator.com/item?id=14988157 The top comment said: > This basically adds another set of tools to the architectural-level attack toolbox. From reading this I expect we'll see some interesting developments in the future. And of course there's an obligatory comment beginning with "this cannot possibly work... "
  - wilun 9y ago
    > And of course there's an obligatory comment beginning with "this cannot possibly work... " its a good point about TLB and VIPT but I don't think this closes the whole class of potential issue; if too-much speculative execution is performed (even just a little bit, even just when you use some obscure instructions) on anything data depend that has been speculatively loaded before privilege checking, I guess its possible to recover the data.
- wilun 9y ago
  Ok so it seems that Intel CPU do some speculative execution on priviledged data from unpriviledged code, including from (at least some and at least part of) separate following instructions. Given the microarchitectural complexity and the already well-known side channel attacks, I would not be surprised at all if someone just finished the work and demonstrated that you can actually read priviledged data with a correct reliability. This might even not be very hard. You can think of prefetching, TLB, cache, hyperthreading, and any combination of those and other features. I'm 90% convinced there is no way Intel managed to close all the side-channels on such a complex architecture, so if they really do continue too much speculative execution I think they (well, actually we :p ) are owned. Note that under Linux x64 IIRC the whole physical memory is mapped in kernel pages... playing with some adjusting variables, if this theory is correct, I don't see why we could not read all of it. Might be the same under Windows. I've not checked in depth yet but it could match with all the technical facts we have: very important bug for which the semi-rushed workaround with high perf impact will be backported; affect general purpose OSes but IIRC does not affect some hypervisors (I guess they already do not map at all the pages of other systems while one is running), does not affect AMD (or maybe at least not this way and KPTI can not fix it for them) because of their microarch, involves data leak.

acoye 9y ago

Do you think this could be within the rather new Intel AVX 512 ISA or older intel CPUs like Sandy Bridge (first AVX chip) could also suffer? - edit - I checked Ryzen ISA, they support AVX2. So probably AVX512 is the issue.

rphlx 9y ago
It has nothing to do with AVX AFAICT. They are going to set X86_BUG_CPU_INSECURE [1] on all public Intel CPUs, including old ones that lack AVX (Core2, etc). [1] I do hope they rename that flag to something like X86_BUG_NEEDS_PTI as the current name is bloody abysmal: way too broad and ambiguous, as if this is the only insecurity that ever has or ever will impact x86.
- wilun 9y ago
  Well that very name hints that it is probably a very annoying bug, with an impact way more annoying that a simple ASLR address leak or data access trace (hell, Intel does not even consider side-channel data access / tlb tracing to SGX a vuln, so this has to be better than that kind of issues...)
fulafel 9y ago
Everything so far hints at a microarchitecture bug, not a ISA specific.

wilun 9y ago

I guess Intel decided to speculate data access regardless of privilege level of the target address, with the theory that what has been successfully speculated can't be accessed anyway before the permission are really checked, and somebody found a bug (or given all Intel processors are taggued as unsecure, maybe a quasi-architectural hole) that let read the speculated data or a significant subset or trace of it. My wild guess is that you can read a good portion (if not all) of the memory (or a significant subset or trace of it) of the whole computer from unprivileged userspace programs.

zimmerfrei 9y ago
Could this be possibly fixed with a microcode update in the future (at least for most recent models for which Intel is still bound to some kind of warranty)?
- justincormack 9y ago
  I think probably not, I think it may be too fundamental. But perhaps there is a mitigation if only a few instructions cause the leak and they can disable those in speculation. Performance hit could be bad though, worse than the Linux fix.
rst 9y ago
One possible vector suggested by Matt Tait (pwnallthethings) on Twitter: if speculative operations can influence what the processor does with the cache, the results can be observed with cache timing attacks. If the branch predictor reads the results of speculative operations, it's real easy, as he suggests here: https://twitter.com/pwnallthethings/status/947978927284383744 https://twitter.com/pwnallthethings/status/94797892728438374... but (as he notes elsewhere) there are plenty of other channels in an Intel processor for information to leak...
- Taniwha 9y ago
  my guess is that the cache tags or tlb entries loaded on failed speculative accesses are wrong (maybe the valid bit is set but the address wasn't changed, or the user/supervisor protections are munged), that could leave you with a cache line or page tagged as user accessible but really protected kernel data

slackingoff2017 9y ago

maybe it has to do with CR3 register? https://patchwork.kernel.org/patch/10138835/ https://patchwork.kernel.org/patch/10138835/ Edit: switched to link without AD cancer

bitexploder 9y ago
I think they are just using the CR3 register to implement the fix. The actual side channel will be something a bit more esoteric. Something like this: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/ https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...

jedisct1 9y ago

They might have succeeded to make it work: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/ https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...

Pyxl101 9y ago
Previously posted on HN as well: https://news.ycombinator.com/item?id=14988157 https://news.ycombinator.com/item?id=14988157 The top comment said: > This basically adds another set of tools to the architectural-level attack toolbox. From reading this I expect we'll see some interesting developments in the future. And of course there's an obligatory comment beginning with "this cannot possibly work... "
- wilun 9y ago
  > And of course there's an obligatory comment beginning with "this cannot possibly work... " its a good point about TLB and VIPT but I don't think this closes the whole class of potential issue; if too-much speculative execution is performed (even just a little bit, even just when you use some obscure instructions) on anything data depend that has been speculatively loaded before privilege checking, I guess its possible to recover the data.
wilun 9y ago
Ok so it seems that Intel CPU do some speculative execution on priviledged data from unpriviledged code, including from (at least some and at least part of) separate following instructions. Given the microarchitectural complexity and the already well-known side channel attacks, I would not be surprised at all if someone just finished the work and demonstrated that you can actually read priviledged data with a correct reliability. This might even not be very hard. You can think of prefetching, TLB, cache, hyperthreading, and any combination of those and other features. I'm 90% convinced there is no way Intel managed to close all the side-channels on such a complex architecture, so if they really do continue too much speculative execution I think they (well, actually we :p ) are owned. Note that under Linux x64 IIRC the whole physical memory is mapped in kernel pages... playing with some adjusting variables, if this theory is correct, I don't see why we could not read all of it. Might be the same under Windows. I've not checked in depth yet but it could match with all the technical facts we have: very important bug for which the semi-rushed workaround with high perf impact will be backported; affect general purpose OSes but IIRC does not affect some hypervisors (I guess they already do not map at all the pages of other systems while one is running), does not affect AMD (or maybe at least not this way and KPTI can not fix it for them) because of their microarch, involves data leak.