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

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 key and remote attestation. That's about as bad as it gets. Because SGX is primarily about encrypting RAM, anything that pops L1 cache is game over and this is a stark reminder of that fact.

- The second attack that fell out of this allows you to read arbitrary L1 cache memory, across kernel-userspace or even VM lines.

The good news here is that the mitigation is somewhat straightforward. It's a pure L1d attack: flush L1d (or prevent things from accessing the same L1d via e.g. core pinning) and you're fine.

If there was any doubt left that speculative execution bugs were an entire new class and not just a one-off gimmick...

If helpful a few Cloud Providers Responses:

Google Cloud

- Google Cloud's protections against this new vulnerability: - https://cloud.google.com/blog/products/gcp/protecting-agains...)

- GCE Related information: - https://cloud.google.com/compute/docs/security-bulletins

- GKE Related information: - https://cloud.google.com/kubernetes-engine/docs/security-bul...

Oracle Cloud

- https://blogs.oracle.com/oraclesecurity/intel-l1tf

Azure

- https://blogs.technet.microsoft.com/virtualization/2018/08/1...

If hyper-threading should be disabled for maximum security, this is good for AMD CPUs which maximize cores per socket.

2 months ago thread on OpenBSD and hyper-threading: https://news.ycombinator.com/item?id=17350278

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?

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.

I'm tempted to just buy the cheapest 8th gen intel cpu and play with that to extract widevine keys from sgx

What is the net performance impact of all these Meltdown, Spectre, now Foreshadow mitigations?

-10%? -20%? -30%?

Have we gone back 3 CPU generations?

What secrets do typical VM hosts (like cloud service providers) have that must be protected from guests?

Interestingly, the upcoming CPUs with built-in resistance to Meltdown (new MSR bit RDCL_NO set to 1) will also be immune to L1TF already.

Can anyone "explain like I'm 5" this issue?