101–110 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.
I upgraded from an i7-2600 to an 1800X over a year ago. Once the memory issues were solved (running at 3200 MHz vs ~2800 MHz), I've been happy with my purchase.
What was the memory problem specifically, and how did you solve it, if you don't mind going into that?
Earlier quoted context omitted.
I mean, the V bit, and the other contexts are just PTE permissions. It's literally the same root cause as meltdown, that page table faults occur particularly asynchronously on Intel hardware and speculation occurs past those faults.
The root cause is the same but it's a different kind of page fault, and the effect is that you cannot read data that is not already present in the cache. On the other hand, meltdown doesn't break through the guest-host barrier when EPT is active. Yes, deep down they happen for the same reason, but then so does Spectre as well.
They're both around how page faults are asynchronous at a uArch level on Intel, and not any of the other vendors. This and Meltdown don't apply to AMD or ARM.
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 lets you extract the sealing key and remote attestation. That's about as bad as it gets. 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 clai…
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 lets you extract the sealing key and remote attestation. That's about as bad as it gets. 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 clai…
It gets worse, if the adversary has root they can force all the data in L1 cache. This allows them to read all memory pages of an executed and non-exuctuted encalve.
There is nothing what can be done against this from the enclaves point of view.
Getting the SGX attestation key would permanently break SGX-based blockchain (Hyperledger Sawtooth?) mining, if I understand correctly. It's amazing that (if this is correct) this vulnerability has permanently broken a large software project.
Fuck SGX. Fuck it long and hard. Breaking anything that enables DRM is a win in my book.
Earlier quoted context omitted.
The closest alternative would be ARM On the contrary there's SPARC, MIPS, PA-RISC, POWER and a whole heap of others that perhaps were written off prematurely. Need to move quickly tho' while some vestiges of expertise still remain.
I'd argue that POWER is still alive and well.
AWS bulletin: https://aws.amazon.com/security/security-bulletins/AWS-2018-... . Amazon Linux bulletin: https://alas.aws.amazon.com/ALAS-2018-1058.html RHEL patches are out. CentOS after delay, presumably. Nothing yet for Debian/Ubuntu. TL;DR: AWS is patched. Go update your kernel (especially if you run other people's code).
Ubuntu: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/L1TF
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1787127
Earlier quoted context omitted.
>> - It lets you extract the sealing key and remote attestation. That's about as bad as it gets. 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 clai…
Agreed. > Only the CPU (silicon or microcode) can assist you in the flushing of L1 when you exit enclave mode. This seems correct, upon double-checking. The interrupt process within SGX is called Asynchronous Enclave Exit (AEX) and does not give the enclave an opportunity to run any code upon interrupt, though it is possible to run code upon every enclave entry (via code placed at the Asynchronous Entry Pointer). I'm…