Hacker News Reader

Comment by justincormack | Hacker News Reader

Looks like it is speculative execution based, and does not affect AMD

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.

View on HN

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.

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)?

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.

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/94797892728438374...

but (as he notes elsewhere) there are plenty of other channels in an Intel processor for information to leak...

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

Perhaps an interaction with conditional branches and cache timing? You could then extract individual bits from privileged memory by having the CPU pull in specific cache lines as part of a speculatively executed branch on the value of the bit.

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

Previously posted on HN as well: 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... "

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

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.

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

That was known since pentium 3 times, I wonder why nobody thought of this as a wonderful exploit target before

>I'm 90% convinced there is no way Intel managed to close all the side-channels on such a complex architecture

This is why one should not use verilog and run formal validation of all and everything related to hdl code

What should one use instead? VHDL, Bluespec, Chisel? I don‘t know of any solution that makes verification significantly easier compared to SystemVerilog.

It will be VHDL for the reason it removes a lot undefined behaviours by design.

Tooling support for VHDL is lacking thought, any big company with in house formal verification must have their own tooling...

What undefined behaviours are those?

tricky grammar. You mean formal, mathematical verification instead of simulation, I suppose, but I am not aware of any different method.

Yes, mathematical verification. Normally, for an any much expensive tape out a partial mathematical verification is done with tooling on hand in addition to brute force simulation.

Ideally, a much closer to complete verification should be done in addition to simulation, like a mathematical proof that register content will never be like set A if inputs are set B

maybe it has to do with CR3 register? https://patchwork.kernel.org/patch/10138835/

Edit: switched to link without AD cancer

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

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.

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.

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

Everything so far hints at a microarchitecture bug, not a ISA specific.

Reply on news.ycombinator.com