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

61–70 of 119 posts

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

#61

Post by Kliment »

h4b4n3r0 wrote: post #57
_msw_ wrote: post #50

Earlier quoted context omitted.

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: E…

Um, no. If I schedule a micro instance in a particular zone and nothing else, for the duration of my timeslice the VM will have to monopolize the core. Optimal use of vCPUs would demand that two VM threads get scheduled to the core to take advantage of HT, which Google says it won’t do. Timeslicing doesn’t solve this problem. At least that’s my reading of what they said.

timeslicing works fine, you just have to flush the cache when switching

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

#62

Post by deathanatos »

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…

> Given the hypervisor on EC2 is opaque to me, I'm not sure how I'm supposed to avoid co-tenanting in a risky fashion.

In Linux, at least, the Xen hypervisor on EC2 exposes some information about itself at /sys/hypervisor. In particular, I think /sys/hypervisor/uuid would allow you to detect co-tenanting (between two VMs of your own).

Not saying that I think you should do that, or that'd I'd want to — it'd be a PITA to coordinate amongst VMs, and I'm not sure it would matter (what if you're co-tentant w/ a malicious VM? even if you detect it, how do you get out of it?). That is, inside the VM seems like wholly the wrong place to attempt to deal with this. But I don't think many people realize /sys/hypervisor exists.

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

#63

Post by ungamed »

jshap70 wrote: post #54
sabas123 wrote: post #40

Earlier quoted context omitted.

> and L1 is flushed before transition from one VM to another. Is this true?

it's what the Google blog post was indicating

I believe that this is likely true as they seemed to implement this for the TLbleed flaw.

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

#64

Post by userbinator »

miloignis wrote: post #43

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.

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

#65

Post by dnautics »

slededit wrote: post #17
colechristensen wrote: post #9

Earlier quoted context omitted.

It's probably time for a new architecture that isn't so convoluted with decades of optimizations and iterative improvements. 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.

You won't make any CPU of reasonable performance without speculative execution and all the rest. Your limited by data dependencies and the only way to break them is to "cheat". Unless your willing to run on the equivalent of a Cortex-M0 then you have to live with it.

I hear delay slots aren't so bad, and compiler optimizations have gotten really good since the itanium days when they last (half-hearted) tried vliw

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

#66

Post by slededit »

dnautics wrote: post #65
slededit wrote: post #17

Earlier quoted context omitted.

You won't make any CPU of reasonable performance without speculative execution and all the rest. Your limited by data dependencies and the only way to break them is to "cheat". Unless your willing to run on the equivalent of a Cortex-M0 then you have to live with it.

I hear delay slots aren't so bad, and compiler optimizations have gotten really good since the itanium days when they last (half-hearted) tried vliw

Delay slots are merely the pipeline of the uarch peeking through, its bad practice because you'll probably want to change the pipeline depth at some point. Other uarchs have them but they hide them from the public API.

VLIW only removes the logic to detect data dependency - it doesn't workaround the actual need to wait for data to be ready.

None of this has much to do with speculative execution which is guessing which way a branch will go. You simply can't have what would be considered a modern computer without it.

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

#68

Post by Dylan16807 »

jshap70 wrote: post #39
ssambros wrote: post #36

Earlier quoted context omitted.

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.

512 entries, 12 cycles to refill each entry from L2, at 3GHz that's only 2 microseconds worst case to refill the L1 cache. And that's if you keep the same task in it. If you're switching tasks most of it is going to get evicted anyway.

GCE uses KVM, which defaults to the linux scheduler with time slices from 0.75ms to 6ms, so the extra impact should be negligible. It's possible they tuned it weirdly, but I can't think of any reason to do so.

Flushes that occur from hypervisor calls could possibly have an impact, but those will happen whether you share a CPU or not.

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

#69

Post by Dylan16807 »

h4b4n3r0 wrote: post #57
_msw_ wrote: post #50

Earlier quoted context omitted.

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: E…

Um, no. If I schedule a micro instance in a particular zone and nothing else, for the duration of my timeslice the VM will have to monopolize the core. Optimal use of vCPUs would demand that two VM threads get scheduled to the core to take advantage of HT, which Google says it won’t do. Timeslicing doesn’t solve this problem. At least that’s my reading of what they said.

> Optimal use of vCPUs would demand that two VM threads get scheduled to the core to take advantage of HT

It would.

So those cores won't be used optimally. No big deal.

Post reply on HN