4 ms·
Do all these vulnerabilities mean that manufacturers will have to remove those optimizations, rendering the cpu slower? It seems to me that extracting or injec
by d--b 7y ago
Do all these vulnerabilities mean that manufacturers will have to remove those optimizations, rendering the cpu slower?
It seems to me that extracting or injecting data that way is very hard to do, and is likely to return very little information.
Is the tradeoff something like: we should prevent the one in a hundred billion chance that my cpu leaks a critical password to some intruder one day at the cost of rendering all my processes 30% slower?
- rishabhd 7y agoI think it already happened, where the flaw itself was critical and the performance impact was substantial. See Zombieload for reference. 1) https://venturebeat.com/2019/05/14/intel-zombieload-flaw-forces-os-patches-with-up-to-40-performance-hits/ https://venturebeat.com/2019/05/14/intel-zombieload-flaw-for... 2) https://zombieloadattack.com/ https://zombieloadattack.com/
- 2J0 7y agoCan I restate the go question as "is complexity of the machine effectively security by obscurity and effective in practice for reliance upon?" Really how much unnecessary complexity is traversing boundaries we can shut down or at least gate effectively? My company has used CICS for this purpose since forever and we're not so much a legacy that you will think about our architecture in this way if we talked about it, but CICS is a very rare interface in this era.
- ghaff 7y agoWe call it serverless now :-) (I'm joking a bit but there are similarities.)
- gameswithgo 7y agoGoing to be worse than 30% slower by a lot.
- BoorishBears 7y agoWhat does this statement even mean? 30% slower for what? What workload? What environment? I can’t even ask what your source on it being “worse than 30%“ because that statement doesn’t mean anything... people keep attaching percentages to these vulnerabilities that really mean nothing for any general use case, to the point you can’t even compare them to each other! I imagine your answer is going to be “well these mitigations are going to be more slower than the last ones” Do these vulnerabilities and the last live on the same hot paths? Are you privy to some information we’re all lacking here that lets you just throw out a statement like this?
- redrabbyte 7y agothere are some (non-optimal) estimates in the paper, tl;dr it's not great ;) some more technical info here https://software.intel.com/security-software-guidance/insights/optimized-mitigation-approach-load-value-injection https://software.intel.com/security-software-guidance/insigh...
- BoorishBears 7y agoExcept how many lay people were running workloads where serializing SGX loads is back breaking? The tone of the original comment replied to definitely came from personal computing slant...
- saagarjha 7y agoThe problem isn't limited to SGX; it's just that nobody has tried it against e.g. the kernel. If someone figures that out you're going to be seeing that performance hit come there, too.
- redrabbyte 7y agobesides drm stuff like netflix (don't know if it's back breaking there), virtually none, of course unless someone publishes a very practical attack from userspace, I don't think this will affect personal computing atm
- cesarb 7y agoWhat's probably going to happen is more isolation. SGX is a target for these vulnerabilities because it's a separate mode of the same processor core which runs normal software; were it on a dedicated core, it wouldn't be vulnerable. In the same way, the kernel can be attacked by user processes (and processes can attack each other) only because they share the same core. So I'd expect to see for instance the kernel running on a set of cores separate from user software (probably using a ring buffer interface for most system calls, like io_uring), and the hardware state being totally flushed when switching a core to another process.
- saagarjha 7y ago(This is also slower.)