81–90 of 119 posts
We're at a stage where to be safe on x86 we need to have multiple microcode and kernel layers to be safe. At which point do we agree the performance increases over the last 20 years have been built on sand and move elsewhere?
I think everyone can agree that CPU progress has been largely made from sand, yes.
Earlier quoted context omitted.
SGX Remote Attestation was built specifically to deal with events like this. Intel starts to reject attesting to vulnerable microcode revisions after some period following disclosure. In this case, they even postponed disclosure until patched microcode revisions were available and those revisions already required for successful attesation. If said SGX application wasn't built around this model then it's probably not…
Isn't this pretty much a no-go for any large public software project, given that microcode updates often depend on the OEMs, which are notoriously bad about supporting devices older than about a year?
Earlier quoted context omitted.
Re-read what I wrote above. It covered both simultaneous and sequential sharing. Here is the part you are concerned about: instances do not simultaneously share cores with other customer instances via SMT .
Re-read what I wrote. Imagine a machine with 8 cores and 16 hyperthreads. Now imagine you need to optimally use the execution ports in each core. To do that you would need to have 16 VM threads all feeding the ports simultaneously, 2 per core. If all your workloads on that machine are from different customers, you can’t do more than 8. If you timeslice more than 8, then the question is, what is it that you’re selling…
> If it’s a timesliced core, then it’s not what they say they’re selling (a hyperthread).
vs.
_msw_:
> A core can be sequentially time sliced between customer instances when you use a fractional (m3.medium) or burst (T2 instances) CPU instance type.
AWS instance types page ( https://aws.amazon.com/ec2/instance-types/ ):
> Each vCPU is a hyperthread of an Intel Xeon core except for T2 and m3.medium.
This is _bananas_. - Unlike previous speculative execution attacks against SGX, this extracts memory "in parallel" to SGX, instead of attacking the code running in SGX directly. It always works: it doesn't require the SGX code to run and it doesn't require it to have any particular speculative execuction vulnerability. This also means existing mitigations like retpolines don't work. - It lets you extract the sealing…
It could have definitely been worse, with the leak of the fused secrets or a breach to integrity of the microcode (the two things that together constitute the TCB, which put simply is the only piece of the system you assume will never be broken).
All in all, assuming a microcode update can counter the attack as Intel claims, sealing and attestation secrets will be rekeyed via the KDF rooted in the fused keys, so that you can start afresh.
Of course, operationally speaking, that is a total pain but it is frankly remarkable to see this kind of deep recovery strategy finally built into consumer devices (and yes, I know DRM is unfortunately the main driver, but there are still some very legitimate use cases).
>> flush L1d (or prevent things from accessing the same L1d via e.g. core pinning) and you're fine
No, you are not fine. As the paper explains, an adversary (which is by definition more privileged than you are) can operate between the moment you use secrets in L1 and the moment you flush them out. Only the CPU (silicon or microcode) can assist you in the flushing of L1 when you exit enclave mode.
Earlier quoted context omitted.
Or just keep using AMD CPUs, because yet again they are unaffected https://www.amd.com/en/corporate/security-updates
I'm seriously thinking about getting an AMD CPU for my desktop when this i7 4770k finally needs replacing.
Earlier quoted context omitted.
I'm seriously thinking about getting an AMD CPU for my desktop when this i7 4770k finally needs replacing.
OTOH it seems like all the major cloud providers are still happy using Intel. They probably have a pretty good reason to do so.
We introduced some AMD servers in January, and the setup had its ups and downs. First We had to go through multiple BIOS updates for stability reasons, also kernel updates kept improving overall experience regarding the CCX architecture... I mean they're working, but Intel systems have almost always delivered a plug and play experience for the last decade or so.
Earlier quoted context omitted.
It's probably time for a new architecture that isn't so convoluted with decades of optimizations and iterative improvements. It's also time for a computer system with one and only one general purpose processor (no tiny CPUs in storage or "system management" or every other device) Probably something like a programming language/OS/computer system written new with a CPU based on current GPU designs.
> no tiny CPUs That is far more a constraint than you think. Probably quite hard to have even a gigabit Ethernet subsystem without it.
Of course no offloading, but you wouldn't notice any performance drops, if the ring buffers are large enough.
Earlier quoted context omitted.
Re-read what I wrote. Imagine a machine with 8 cores and 16 hyperthreads. Now imagine you need to optimally use the execution ports in each core. To do that you would need to have 16 VM threads all feeding the ports simultaneously, 2 per core. If all your workloads on that machine are from different customers, you can’t do more than 8. If you timeslice more than 8, then the question is, what is it that you’re selling…
You: > If it’s a timesliced core, then it’s not what they say they’re selling (a hyperthread). vs. _msw_: > A core can be sequentially time sliced between customer instances when you use a fractional (m3.medium) or burst (T2 instances) CPU instance type. AWS instance types page ( https://aws.amazon.com/ec2/instance-types/ ): > Each vCPU is a hyperthread of an Intel Xeon core except for T2 and m3.medium.