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

111–119 of 119 posts

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

#111

Post by Leonid99 »

wlll wrote: post #99
hexane360 wrote: post #87

Earlier quoted context omitted.

OTOH it seems like all the major cloud providers are still happy using Intel. They probably have a pretty good reason to do so.

It's something of a self fulfilling prophecy I suspect. People use Intel because people use Intel. "Nobody got fired for buying IBM" etc. As a sysadmin (who admittedly doesn't deal with hardware much) these issues with Intel chips (the mitigation of which can seriously decrease performance), and the relative ease with which AMD has come through the problems make me wonder if we would be better with AMD. I'm reminded…

> and the relative ease with which AMD has come through the problems make me wonder if we would be better with AMD.

I think the only reason this is the case is the difference in market share. There are much more Intel processors out there, so finding an Intel vulnerability makes a much better academic paper (and much more lucrative for bad actors).

AMD might have made some inroads into the enthusiast market lately, but with cloud providers they are basically non-existent. These guys buy (or manufacture) servers by tens of thousands. They hate rebooting servers, even if they got a VM live-migration stuff worked out (as everybody does these days). BIOS and RAM problems that people mention here make AMD a complete no-go.

I'm sure that now there are people at Amazon/Google/Microsoft thinking hard about reducing their dependence on Intel, but I doubt we will see any difference for years.

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

#112

Post by smolder »

Dylan16807 wrote: post #69
h4b4n3r0 wrote: post #57

Earlier quoted context omitted.

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.

Yeah, and the throughput of HT threads on an already busy core was not that high, last I checked.

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

#113

Post by cowboysauce »

aosaigh wrote: post #105

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

Modern processors execute instructions speculatively, that is without knowing if the instructions should actually run. If it turns out they weren't supposed to be executed then the processor undoes effects of the instructions. However, not everything is undone. If the speculatively executed instructions access RAM, then they can move data in and out of the cache. By measuring how long it takes to read memory, you can tell what memory the speculatively instructions accessed.

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.

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

#114

Post by bonzini »

monocasa wrote: post #103
bonzini wrote: post #38

Earlier quoted context omitted.

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.

I mean, no, they're way closer than Spectre is. They're both around how page faults are asynchronous at a uArch level on Intel, and not any of the other vendors. This and Meltdown don't apply to AMD or ARM.

Yes, it's true they're close. The lazy FPU state restore bug is similar, too. Though, Meltdown did apply to some ARM 64-bit processors.

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

#115

Post by rurban »

gaius wrote: post #91
rurban wrote: post #78

Earlier quoted context omitted.

Sparc, Tilera and Parallela are unfortunately gone. I had high hopes into the latter two, esp. since Grid CPU's are perfect for machine learning. Much better than GPU's.

Fujitsu still have SPARC on their roadmap http://www.fujitsu.com/global/products/computing/servers/uni...

Roadmap yes, but Linux support no. https://wiki.debian.org/Sparc64

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

#116

Post by Sohcahtoa82 »

dannyw wrote: post #80

What is the net performance impact of all these Meltdown, Spectre, now Foreshadow mitigations? -10%? -20%? -30%? Have we gone back 3 CPU generations?

This is something I'd really like answered.

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.

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

#117

Post by cthalupa »

h4b4n3r0 wrote: post #90
cthalupa wrote: post #84

Earlier quoted context omitted.

You: > If it’s a timesliced core, then it’s not what they say they’re selling (a hyperthread). vs. _msw_: > A core can be sequentially time sliced between customer instances when you use a fractional (m3.medium) or burst (T2 instances) CPU instance type. AWS instance types page ( https://aws.amazon.com/ec2/instance-types/ ): > Each vCPU is a hyperthread of an Intel Xeon core except for T2 and m3.medium.

Not in Google’s case. There vCPU == hyperthread. To quote https://cloud.google.com/compute/docs/machine-types : "For the n1 series of machine types, a vCPU is implemented as a single hardware hyper-thread". One more area where Google is more explicit. Only their partial vCPU instances are timesliced: "Shared-core machine types provide one vCPU that is allowed to run for a portion of the time on a single hardware hype…

Except this thread has been about AWS, not Google.

Who cares how Google defines things?

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

#118

Post by zaarn »

pmccarren wrote: post #81
zaarn wrote: post #14

Earlier quoted context omitted.

I think everyone can agree that CPU progress has been largely made from sand, yes.

Hah, splendid pun. Well done!

I'm torn if I should be proud or disappointed that my highest voted comment is a pun. On HN and on a thread that is fairly serious considering it's about modern CPUs catching fire (though I heard Intel was independently working on that catch-fire feature with their newest 28-core release)

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

#119

Post by h4b4n3r0 »

cthalupa wrote: post #117
h4b4n3r0 wrote: post #90

Earlier quoted context omitted.

Not in Google’s case. There vCPU == hyperthread. To quote https://cloud.google.com/compute/docs/machine-types : "For the n1 series of machine types, a vCPU is implemented as a single hardware hyper-thread". One more area where Google is more explicit. Only their partial vCPU instances are timesliced: "Shared-core machine types provide one vCPU that is allowed to run for a portion of the time on a single hardware hype…

Except this thread has been about AWS, not Google. Who cares how Google defines things?

It was about both.
Post reply on HN