Understanding L1 Terminal Fault aka Foreshadow: What You Need to Know

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.

(Disclaimer: I work at AWS, but I am not linking this in any sort of official capacity. I don't know any more details beyond what is listed in that bulletin, and can't answer any questions related to this, unfortunately.)

However, GCE does offer shared core machine types (f1-micro and g1-small) with 0.2 and 0.5 vCPUs respectively. This seems to contradict their statement (unless the cores are not shared after all, but that doesn’t make sense from an economical standpoint).

Also, they offer machines with one vCPU, but since a vCPU is only a single hyper-thread and not a full core, this still allows for the core to be shared over multiple VMs. If this means that Google will stop using hyperthreading and instead give everyone a full CPU core per vCPU, that will likely give noticeable performance benefits (but cost more for them).

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.

The closest alternative would be ARM. In any case, it's a massive undertaking.

If said SGX application wasn't built around this model then it's probably not a valid use case of SGX..

Breaking anything that enables DRM is a win in my book.

I'm still running an i7-3770k on my desktop at home. I was considering upgrading when the 9th gen comes out in October, but if the Spectre/Meltdown/Foreshadow fixes have a significant performance impact, it won't be worth spending the money. As it is, I'll already need a new motherboard and RAM, since I'm still on DDR3.

Speculative execution is what allows Meltdown to work. You make the processor speculatively execute an access to kernel memory, then access a memory address based on the value of the data read from kernel memory. Intel processors preform the speculative execution without first checking if the memory access in allowed while AMD processors check before the speculative execution. This is why AMD processors aren't vulnerable to Meltdown.

SGX was thought not be vulnerable to a speculative execution attack because attempts to access SGX memory, without having the necessary access, just yield -1 for reads and writes are ignored, as opposed to causing an exception as with access to kernel memory. However, if the SGX memory is marked as not-present, then attempts to read the memory will trigger a page fault exception. The page fault circumvents the normal SGX protection and allows the memory to be read by speculatively executed instructions.