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

31–40 of 119 posts

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

#31

Post by h4b4n3r0 »

rodgerd wrote: post #29
gregdunn wrote: post #18

Earlier quoted context omitted.

For AWS: https://aws.amazon.com/security/security-bulletins/AWS-2018-... (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.)

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?

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

#32

Post by garethl »

rodgerd wrote: post #29
gregdunn wrote: post #18

Earlier quoted context omitted.

For AWS: https://aws.amazon.com/security/security-bulletins/AWS-2018-... (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.)

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…

It does say, "All EC2 host infrastructure has been updated with these new protections, and no customer action is required at the infrastructure level."

"Meanwhile, we suggest using the stronger security and isolation properties of EC2 instances to separate any untrusted workloads." As I read it, it is talking about running code within your instance - if you have untrusted workloads, rather run them in a separate instance, so as not to encounter issues like this cross-process.

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

#33

Post by rodgerd »

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?

Or map pairs of hyperthreads to each requested vCPU, or disable hyperthreading. Which kills co-tenancy overcommit and makes the infra more expensive for a cloud provider.

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

#34

Post by markdoubleyou »

rodgerd wrote: post #29
gregdunn wrote: post #18

Earlier quoted context omitted.

For AWS: https://aws.amazon.com/security/security-bulletins/AWS-2018-... (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.)

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…

Amazon offers "dedicated hosts" and "dedicated instances", which you can specify in the "tenancy" field when launching an EC2 instance. I bet that's the stronger isolation that they're referring to. Costs more, though.

https://aws.amazon.com/ec2/dedicated-hosts/

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

#35

Post by Ar-Curunir »

outworlder wrote: post #16
sofaofthedamned wrote: post #2

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?

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 problem is that hte platform is not well-understood. The design is convoluted and often not well-principled.

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

#36

Post by ssambros »

praseodym wrote: post #30
cobookman wrote: post #10

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/…

Google writes that ‘Google Compute Engine employs host isolation features which ensure that an individual core is never concurrently shared between distinct virtual machines’. 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 s…

I think the key word is 'concurrently'. My guess is that micro and small instances indeed share CPUs, just never 'at the same time' and L1 is flushed before transition from one VM to another.

I work for Google Cloud, but not related to security or OS development, so am not aware how it is actually being done.

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

#37

Post by phire »

praseodym wrote: post #30
cobookman wrote: post #10

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/…

Google writes that ‘Google Compute Engine employs host isolation features which ensure that an individual core is never concurrently shared between distinct virtual machines’. 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 s…

The key word is "Concurrently".

They can give both hyperthreads to one machine for 50ms then both hyperthreads to another machine for 50ms.

For VMs with less than 2 vCPUs I suspect they give them two virtual threads and just schedule them for half the time they would otherwise.

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

#38

Post by bonzini »

monocasa wrote: post #26
bonzini wrote: post #20

Earlier quoted context omitted.

It's not built on meltdown. It's not about violating permissions, it's about treating the contents of a page table as valid even if the page is not present or (in the case of EPT, which is worse) also treating the physical address on the guest as a physical address on the host. However, unlike meltdown it cannot access data that is not already in the L1 cache.

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.

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

#39

Post by jshap70 »

ssambros wrote: post #36
praseodym wrote: post #30

Earlier quoted context omitted.

Google writes that ‘Google Compute Engine employs host isolation features which ensure that an individual core is never concurrently shared between distinct virtual machines’. 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 s…

I think the key word is 'concurrently'. My guess is that micro and small instances indeed share CPUs, just never 'at the same time' and L1 is flushed before transition from one VM to another. I work for Google Cloud, but not related to security or OS development, so am not aware how it is actually being done.

seems slow. Having to flush on every swap, I mean. I wonder if there wont be a move away from offering these kinds of offers: if offering 0.2 of a core means putting in 0.3 effort, that's a 20-30% drop in how many you can run per core.

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

#40

Post by sabas123 »

ssambros wrote: post #36
praseodym wrote: post #30

Earlier quoted context omitted.

Google writes that ‘Google Compute Engine employs host isolation features which ensure that an individual core is never concurrently shared between distinct virtual machines’. 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 s…

I think the key word is 'concurrently'. My guess is that micro and small instances indeed share CPUs, just never 'at the same time' and L1 is flushed before transition from one VM to another. I work for Google Cloud, but not related to security or OS development, so am not aware how it is actually being done.

> and L1 is flushed before transition from one VM to another.

Is this true?

Post reply on HN