Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

redhat.com

Post reply on HN
Print view View original

41–50 of 119 posts

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

#41

Post by lvh »

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...

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

#42

Post by lvh »

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).

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

#44

Post by lvh »

walterbell wrote: post #3

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

To be clear: HyperThreading is relevant but not a panacea here. Disabling HT helps for the hypervisor leak, and while the Intel microcode changes now incorporate HyperThreading status into key generation, we don't know if that prevents the SGX leak. Ensuring untrusted code is on a sibling core and L1 flushes should be a mitigation for the SMM attack (it's identical to the VMM attack in that sense).

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

#45

Post by Aloha »

gaius wrote: post #27
outworlder wrote: post #16

Earlier quoted context omitted.

There is a lot of legacy cruft in x86, but it's the devil we know. After decades of use, we are still discovering vulnerabilities, in a platform thought to be well-understood. The closest alternative would be ARM. In any case, it's a massive undertaking.

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.

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

#46

Post by maccio92 »

sebazzz wrote: post #25
c2h5oh wrote: post #5

Earlier quoted context omitted.

Or just keep using AMD CPUs, because yet again they are unaffected https://www.amd.com/en/corporate/security-updates

Never mind that AMD sockets used to last longer (less frequent incompatible socket changes), which meant you could do longer with your motherboard. Not sure if that still is the case though.

this is still the case

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

#47

Post by haimez »

lvh wrote: post #42

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).

404 not found on the AWS link.

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

#48

Post by officialchicken »

lvh wrote: post #42

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

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

#49

Post by draw_down »

lvh wrote: post #44
walterbell wrote: post #3

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

To be clear: HyperThreading is relevant but not a panacea here. Disabling HT helps for the hypervisor leak, and while the Intel microcode changes now incorporate HyperThreading status into key generation, we don't know if that prevents the SGX leak. Ensuring untrusted code is on a sibling core and L1 flushes should be a mitigation for the SMM attack (it's identical to the VMM attack in that sense).

No one claimed “panacea”

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

#50

Post by _msw_ »

h4b4n3r0 wrote: post #31
rodgerd wrote: post #29

Earlier quoted context omitted.

Contrast: "Meanwhile, we suggest using the stronger security and isolation properties of EC2 instances to separate any untrusted workloads." with: "Google Compute Engine employs host isolation features which ensure that an individual core is never concurrently shared between distinct virtual machines. This isolation also ensures that, in the case that different virtual machines are scheduled sequentially, the L1 data…

How is the latter possible in case of 1 vCPU VM instances if 1 vCPU == 1 hyperthread? Do they give you a full core in this case?

1 vCPU instances do not simultaneously share cores with other customer instances via SMT (Intel Hyper-Threading Technology). A core can be sequentially time sliced between customer instances when you use a fractional (m3.medium) or burst (T2 instances) CPU instance type.

https://aws.amazon.com/ec2/instance-types/ includes a note that provides some additional information about when vCPUs utilize Intel HT Technology: Each vCPU is a hyperthread of an Intel Xeon core except for T2 and m3.medium. (emphasis added)

https://aws.amazon.com/ec2/virtualcores/ provides a table of the number of cores allocated per instance. Notice that an instance like m5.large that has 2 vCPUs and 1 core. An instance like t2.small has 1 vCPU and 1 core.

Disclosure: I work for AWS

Post reply on HN