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

Intel SA-00145: Lazy FP State Restore

intel.com

Post reply on HN
Print view View original

81–90 of 127 posts

Re: Intel SA-00145: Lazy FP State Restore

#81

Post by ajross »

dnautics wrote: post #78
ajross wrote: post #77

Earlier quoted context omitted.

Shrug. To paraphrase, your argument for "this can be done" is "THIS time will be different I swear!". What will actually happen, of course, is that everyone will put a ASID/PCID as a tag word into all the relevant caches, they'll stop being probe-able from other contexts, and we'll all keep our deep pipelines and speculation and the cache crisis of 2018 will be just a story we tell our grandkids. Much cheaper than a…

you are fundamentally misunderstanding my argument: sometimes it is different. When it is different, it's usually because associated technologies has changed. For ML, it was GPUs and large amounts of data harvestable from the internet (arguably the second one more than the first). The evolutionary development in compilers is a strong argument that it MIGHT happen to end SpecEx. If it doesn't it's probably mostly due…

> If it doesn't it's probably mostly due to technical debt and engineering inertia

You jumped straight from "absence of proof must be proof of the opposite" into as bald a no true scotsmanism as I've seen recently. It's like fallacy central here.

Re: Intel SA-00145: Lazy FP State Restore

#82

Post by nhaehnle »

caf wrote: post #52
Tuna-Fish wrote: post #18

Earlier quoted context omitted.

Completely dropping all forms of speculative execution means dropping overall performance to a tenth of today. There are really hard limits on how fast any operation, especially memory operations, can be done. The way we have made our CPUs faster is by making them do more operations in parallel, at all levels. At the lowest level, in straight line code, this very often requires speculation to achieve. Speculation is…

Except for Spectre variant 1. That will always stay with us, because there is no sensible fix for it. Is it not a feasible fix for Spectre-v1 to have loaded cachelines wait in a staging area, and not actually update the cache hierarchy until the load instruction is retired?

Is it theoretically possible? Maybe. Is it practical? Almost certainly not.

Keep in mind that it's not just the L1 cache you potentially need to worry about, but also all the higher level caches, which are really like remote nodes in a distributed system. Even the last level cache would have to be aware of the current speculation state of all threads in the system, which seems like it would be really expensive.

What's perhaps even worse, you wouldn't be able to hit on speculatively loaded cache lines until they have "committed" (because the resulting change in external bandwidth utilization may be observable from another thread), which would probably kill a lot of the benefits of the cache in the first place.

Re: Intel SA-00145: Lazy FP State Restore

#83

Post by nhaehnle »

wnoise wrote: post #50
Negitivefrags wrote: post #25

Earlier quoted context omitted.

We can't really get rid of speculative execution, but we will effectively need to get rid of the idea that you can run untrusted code in the same process as data you want to keep secure. It's interesting that the future predicted by excellent (and entertaining) talk The Birth & Death of Javascript [1] will now never come to pass. [1] https://www.destroyallsoftware.com/talks/the-birth-and-death...

> We can't really get rid of speculative execution Why not? > but we will effectively need to get rid of the idea that you can run untrusted code in the same process as data you want to keep secure. If we accept that, then we also need to get rid of the idea that we can branch differently in trusted code based on details of "untrusted data".

Your last point is basically what Spectre v1 mitigations are all about, at least if you throw in the word "speculation" somehow. The rule is: don't speculate past branches that depend on untrusted data (though there are certain additional considerations about what the speculated code would actually do).

It's just that there are a lot of branches that don't depend on untrusted data. Speculatively executing past them is perfectly fine and extremely valuable for performance. That's why nobody wants to get rid of speculative execution.

Re: Intel SA-00145: Lazy FP State Restore

#84

Post by rurban »

ajross wrote: post #68
JudasGoat wrote: post #35

Earlier quoted context omitted.

I know the Arm A-53 isn't cutting edge fast, but hardly one tenth. Seeing as the A-53 is unaffected by both Meltdown and Spectre, my assumption was that it didn't use speculative execution.

All CPUs speculate to some extent (branch prediction has been on everything for basically 30 years now). Intel CPUs got hit first because they're the first ones to speculate so deeply that you can discriminate cache behavior like this. The caches and pipelines just aren't big enough elsewhere, but the techniques are all the same.

Nope, Intel got hit because they did it wrong, and the others did it right. If you speculate you need two status registers. One for the good and one for the bad case. Same for meltdown: you need one for the kernel and one for user space. Intel didn't care, others do.

But Intel got the government ("legal") backdoors in. Priorities.

Re: Intel SA-00145: Lazy FP State Restore

#85

Post by cperciva »

caf wrote: post #80
cperciva wrote: post #60

Earlier quoted context omitted.

Sure, but that gives you an even shorter window because the pipeline flushes as soon as the CPU realizes that it mis-speculated.

It is my understanding that you can make that window very long by having the mis-speculated branch depend on a value that has to be loaded from main memory.

Hmm, good point. Yes, that would probably make this much easier to exploit.

Unless the CPU does a partial pipeline flush upon realizing that there would be a trap. I don't know -- do Intel CPUs check for exceptions in order?

Re: Intel SA-00145: Lazy FP State Restore

#86

Post by hinkley »

dralley wrote: post #66
hinkley wrote: post #44

Earlier quoted context omitted.

Contrast this with the Postgres addon community, which has a culture of pushing changes upstream until they no longer have to maintain a fork of the Postgres code. Build a business on a fork, then compartmentalize it until it can run without modifying the core so you can get off the bugfix treadmill.

The changes are all upstream to begin with. It's a fork in the sense that it's heavily diverged from the source of the old kernel, but it's all still backports and not a ton of new development.

Why does it need to be diverged if there is no new functionality in their version? Because they can?

Re: Intel SA-00145: Lazy FP State Restore

#87

Post by caf »

cperciva wrote: post #85
caf wrote: post #80

Earlier quoted context omitted.

It is my understanding that you can make that window very long by having the mis-speculated branch depend on a value that has to be loaded from main memory.

Hmm, good point. Yes, that would probably make this much easier to exploit. Unless the CPU does a partial pipeline flush upon realizing that there would be a trap. I don't know -- do Intel CPUs check for exceptions in order?

Well, they don't for #PF at least, because that's how Meltdown works - I'm not sure if it works differently for #NM though.

Re: Intel SA-00145: Lazy FP State Restore

#88

Post by microtonal »

kbenson wrote: post #67
gicmo wrote: post #19

Earlier quoted context omitted.

RHEL kernels are heavily patched, i.e. stuff gets backported from new kernels, sometimes even from -rc if needed. The version number is therefore not that useful. Some call it a Frankenkernel. :)

The nice thing is that it's all fully documented. If you download the kernel src.rpm[1] and install it, you'll get the kernel RPM spec file in your default RPM build environment paths (or use rpm2cpio $KERNEL_SRPM | cpio -idmv). The way the RPM building works is to take a vanilla kernel and then apply a LOT of individual patch files to it, each with their own entry. Well, at least that's how it was a long time ago wh…

I think maybe RedHat ships the kernel tar mostly pre-patched in-house now.

Yes, this was in the news a couple of years ago. They do not include separate patches anymore:

https://lwn.net/Articles/430098/

https://www.theregister.co.uk/2011/03/04/red_hat_twarts_orac...

Re: Intel SA-00145: Lazy FP State Restore

#89

Post by Animats »

olliej wrote: post #43
JudasGoat wrote: post #35

Earlier quoted context omitted.

I know the Arm A-53 isn't cutting edge fast, but hardly one tenth. Seeing as the A-53 is unaffected by both Meltdown and Spectre, my assumption was that it didn't use speculative execution.

Thought it was effected by spectre - meltdown was the exploit that only effected a subset of the market. Meltdown is specifically due to load speculation happening prior to verifying access permissions. Spectre is more generally due to load speculation modifying the cache while inside a branch speculation context. Basically it effected every high performance cpu in some way. Note that saying there’s a protected/safe…

In this context, getting "affect" and "effect" straight is important.

Re: Intel SA-00145: Lazy FP State Restore

#90

Post by Dylan16807 »

ajross wrote: post #81
dnautics wrote: post #78

Earlier quoted context omitted.

you are fundamentally misunderstanding my argument: sometimes it is different. When it is different, it's usually because associated technologies has changed. For ML, it was GPUs and large amounts of data harvestable from the internet (arguably the second one more than the first). The evolutionary development in compilers is a strong argument that it MIGHT happen to end SpecEx. If it doesn't it's probably mostly due…

> If it doesn't it's probably mostly due to technical debt and engineering inertia You jumped straight from "absence of proof must be proof of the opposite" into as bald a no true scotsmanism as I've seen recently. It's like fallacy central here.

An argument of the form "many X failed, but a new X might not" is not a form of no true scotsman. It would only be no true scotsman if the claim was "X always wins, and Itanium wasn't X"

But anyway I think they're making a fair argument. If something takes an enormous technical effort to switch to, and is similar in performance, nobody is going to put in that effort.

This is emphatically not evidence that the idea "doesn't work".

I believe if you could retroactively wipe out the last decade of improvement on x86 and Arm, and redirect all of that development effort to VLIW, the resulting chips and software would perform just fine by current standards.

Post reply on HN