5 ms·
Intel continues to get beaten up by their decision to defer access checks in speculation. Meltdown, L1TF, and now LVI-stale-data are all rooted in one mistake.
by strstr 7y ago
Intel continues to get beaten up by their decision to defer access checks in speculation. Meltdown, L1TF, and now LVI-stale-data are all rooted in one mistake. Fortunately, the silicon fix for Meltdown appears to mitigate these issues ("RDCL_NO"). But it also introduces LVI-NULL (which is admittedly more restricted, but still problematic).
The Intel deep dive [0] is a pretty solid addition to the original paper [1].
It looks like Ice Lake processors are going to be the first ones that are not affected [2]. Based on the deep dive, it sounds like these still aren't perfect (they don't completely avoid forwarding values to dependent instructions from faulting loads). They instead exhibit some behavior they call "zero-at-ret", which Intel says is not expoitable in practice.
Intel does not explicitly say Ice Lake is zero-at-ret, but reading between the lines this seems to be the case ("parts generally exhibiting Zero-at-ret behavior... will be documented as 'not affected'.") Only Ice Lake is listed as not affected, so they likely would not put this caveat in there if this did not apply to Ice Lake.
[0] https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection#injectnonzerodata https://software.intel.com/security-software-guidance/insigh...
[1] https://lviattack.eu/lvi.pdf https://lviattack.eu/lvi.pdf
[2] https://software.intel.com/security-software-guidance/insights/processors-affected-load-value-injection https://software.intel.com/security-software-guidance/insigh...
- zerkten 7y agoThis is a bit of a naive question, but do the Ice Lake mitigations address any of the performance impact from the software updates that address earlier issues?
- strstr 7y agoDepending on your risk tolerance, mostly yes: 1) You can disable kPTI without opening the door to Meltdown (which let you directly read kernel memory as usermode). 2) You can re-enable hyperthreading while allowing virtualization (VMs) without obvious issues (l1tf used to allow users to read kernel memory through VMs). I don't know which, if any, distros do this, but it's the prudent thing to do if you care deeply about security. (Linux may have the scheduling fixes by now that also fix this, but I honestly haven't followed them, and they didn't have them in like November when I last checked.) Others: 1) I'm honestly unsure if you can recompile kernels without "retpoline", but it's not a super big perf impact anyway, at least not compared to those two mitigations. 2) I'm not super familiar with the "MDS" vulnerabilities, so I don't know how bad the perf impact of their mitigations are, or how bad their impact is. 3) There's some TSX issues, which I'm also unfamiliar with, also probably don't matter much perf wise. If you are paranoid, or have a multi-tenant machine, I'd still leave these on (and I'd particularly leave hyper-threading off, even on AMD), since we haven't stopped seeing new side channels. Hyper-threading is basically asking for problems on multi-tenant machines. Honestly, if your machine is not multi-tenant, and you can tolerate some risk (e.g. you don't care if anyone sitting at your machine can read all of RAM, including potential malware), I'd just disable all this stuff. Unless you've run into particular hiccups (you compile linux kernels all day and you need the extra cores), I wouldn't do it.
- lisnake 7y agoregarding 2): latest betas of ChromeOS disable hyperthreading if one enables builtin Linux VM. Seems overzealous to me, as the OS is not multi-tenant usually
- saagarjha 7y agoI thought that Chrome OS disabled this by default, as MDS crosses privileges boundaries in addition to the VM/host one?
- lisnake 7y agoBy default on my ChromeOS 81 beta HyperThreading is getting disabled only after you start the linux vm. HT stays disabled until you reboot. There is scheduler flag in chrome://flags, but IME it does nothing
- strstr 7y agomeant for [2] to be https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection https://software.intel.com/security-software-guidance/insigh....