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

71–80 of 127 posts

Re: Intel SA-00145: Lazy FP State Restore

#71

Post by _chris_ »

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?

Yes, you can buffer up and kill any misspeculated updates. You have to do this for ALL shared structures, not just data caches. Annoying, but not impossible.

The scarier part is managing bandwidth contention to shared structures.

Re: Intel SA-00145: Lazy FP State Restore

#72

Post by make3 »

cmsimike wrote: post #13

Serious question - should we considering speculative cpu execution to be A Bad Idea (tm) and move on from it (since these problems keep coming up), or is the thought that we more or less have been gaining performance on the back on incorrectly written software (which does not take these speculative execution edge cases into account), and the only forward is patching? I guess a another question I have is can we win th…

maybe only on things that have huge targets on their backs?

Re: Intel SA-00145: Lazy FP State Restore

#73

Post by dnautics »

ajross wrote: post #70
dnautics wrote: post #59

Earlier quoted context omitted.

There are architectural choices for pipelined systems you can make that don't specex, but it requires compiler level optimization to take advantage of them, so it's a chicken and egg problem to get adoption

Been there, done that, didn't work. VLIW has been tried a dozen times and failed every time.

machine learning has been tried a dozen times and failed every time.

Other developments catch up, like compiler technology. Not directly related to branch prediction, but: We are much better at polyhedral optimization than the last time people tried VLIW, for example.

Besides, the last major VLIW push (itanium) DID have SpecEx AND Branch Prediction, and did NOT have delay slots.

Re: Intel SA-00145: Lazy FP State Restore

#74

Post by snuxoll »

vbezhenar wrote: post #26
snuxoll wrote: post #20

Earlier quoted context omitted.

Red Hat backports security fixes, hardware support and certain new features to their kernel packages, staying on a stable kernel version throughout the product lifecycle is what allows them to guarantee a consistent kernel ABI that virtually every other distribution throws to the wayside. Personally I prefer not having third-party kernel modules on my servers break every time I run `yum upgrade` like I do with Fedora…

I'm using HP B120i fakeraid controller with proprietary driver and it broke after 7.4 upgrade, so while they probably doing a good job about binary compatibility (7.5 didn't broke it), it's not ideal.

Unfortunately the kABI does not encompass every symbol exported by the kernel, there is a whitelist maintained in the kernel-abi-whitelists package and scripts to check conformance of a module to the whitelist. Symbols are only ever added throughout the lifecycle of a RHEL release, so anything that conforms to the 7.3 kABI will also work on 7.4 - but if the module uses a symbol NOT whitelisted in 7.3 there's no guarantee the 7.4 update won't break it.

Not that it's much solace when your proprietary blob breaks, but Red Hat does make considerable effort to give vendors a stable target to build against - unfortunately not everyone fully validates conformance which results in the same old problems cropping up from time to time.

Re: Intel SA-00145: Lazy FP State Restore

#75

Post by AstralStorm »

Taniwha wrote: post #57
kinghajj wrote: post #39

Earlier quoted context omitted.

What are your thoughts on the Mill CPU team's claims re: their ISA allowing compilers feasibly to schedule operations statically?

you can do this to some degree on most CPU's - moving loads away from their results being used - compilers, esp on RISC machines with lots of registers, do this today VLIW machines allow you to provide hints about instruction level parallelism without all the superscalar on-the-fly analysis of instruction level data dependencies (so the hardware can do all that rescheduling on the fly). I think that if interlock-free…

Essentially the CPU is running a JIT branch optimization and speculative loads which cannot ever be matched by static optimization. The interesting part is that any JIT compiler that is so dynamic in performance will have these problems.

The solution might be to actually prevent some kind of security important code from being optimized in this way. Say, forcing full cache sync in-order execution for parts of code with no resource sharing between cores.

Re: Intel SA-00145: Lazy FP State Restore

#76

Post by [deleted] »

bdonlan wrote: post #62
caf wrote: post #52

Earlier quoted context omitted.

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?

Loading those cache lines might invalidate an exclusively held cache line on another core. When that core tries to write to that cache line, it can observe a slower write.

[deleted]

Re: Intel SA-00145: Lazy FP State Restore

#77

Post by ajross »

dnautics wrote: post #73
ajross wrote: post #70

Earlier quoted context omitted.

Been there, done that, didn't work. VLIW has been tried a dozen times and failed every time.

machine learning has been tried a dozen times and failed every time. Other developments catch up, like compiler technology. Not directly related to branch prediction, but: We are much better at polyhedral optimization than the last time people tried VLIW, for example. Besides, the last major VLIW push (itanium) DID have SpecEx AND Branch Prediction, and did NOT have delay slots.

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 paradigm shift based on long-since tried and rejected technology.

Re: Intel SA-00145: Lazy FP State Restore

#78

Post by dnautics »

ajross wrote: post #77
dnautics wrote: post #73

Earlier quoted context omitted.

machine learning has been tried a dozen times and failed every time. Other developments catch up, like compiler technology. Not directly related to branch prediction, but: We are much better at polyhedral optimization than the last time people tried VLIW, for example. Besides, the last major VLIW push (itanium) DID have SpecEx AND Branch Prediction, and did NOT have delay slots.

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 to technical debt and engineering inertia, difficulty convincing end users to adopt. There are definitely cases where non specex (vliw or otherwise) can outperform, I have seen it with my own eyes.

Re: Intel SA-00145: Lazy FP State Restore

#79

Post by eridius »

jcranmer wrote: post #42
kentonv wrote: post #30

Earlier quoted context omitted.

> Going forward, the only reasonable assumption is that if you let a third party run their code in a process, no matter how you verify accesses or otherwise try to contain that code, you should assume it has a read access to the entire process. If this is true, it is unbelievably bad for the future of security and computing in general. People throwing around this assertion are, in my opinion, not appreciating how bad…

> Here's how that works: Thank about Haskell, or another purely-functional language. An attacker provides you with a pure function to execute. Because it's a pure function, for some given set of inputs, it will always produce exactly the same output, no matter what machine you run it on, or what else is going on in the background. Therefore, the output cannot possibly incorporate observations from side channels, no m…

If the attacker can do timing on their side in a pure function, then by definition the time the response takes is one of the function inputs.

Re: Intel SA-00145: Lazy FP State Restore

#80

Post by caf »

cperciva wrote: post #60
caf wrote: post #54

Earlier quoted context omitted.

Can't you executive the trapping access in a not-taken speculatively-executed branch à la Meltdown?

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.
Post reply on HN