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

31–40 of 127 posts

Re: Intel SA-00145: Lazy FP State Restore

#31

Post by niftich »

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…

Speculative execution isn't an inherent security risk, but it typically entails a cache fill, which can, if not cleaned up or not isolated, can be used for a timing attack. That's the real issue here: that execution results in mutating a shared datastore, and facts about the likely contents of that datastore can be inferred from performing additional operations and self-measuring aspects of one's own performance.

In the larger sense, mixing various privilege levels on shared hardware is likely a bad idea, despite being fundamental to general-purpose computing. This is because it's fairly difficult to cloak intrinsic "physical" attributes of execution, like execution timing, cache timing, from other processes, and essentially impossible (and/or unreasonable) to cloak it from one's own process. It is both possible for a process to generate lots of side-effects (e.g. IO, cache fill), and for it or another process to try to figure out ways the shared state changes by observing its own execution.

Re: Intel SA-00145: Lazy FP State Restore

#32

Post by yuhong »

Tuna-Fish wrote: post #18
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…

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…

I think Spectre is even less severe then Meltdown though.

Re: Intel SA-00145: Lazy FP State Restore

#33

Post by cmsimike »

Tuna-Fish wrote: post #18
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…

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…

Thank you for your response!

Re: Intel SA-00145: Lazy FP State Restore

#35

Post by JudasGoat »

Tuna-Fish wrote: post #18
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…

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…

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.

Re: Intel SA-00145: Lazy FP State Restore

#36

Post by ndesaulniers »

kanox wrote: post #17

What is the impact of this exactly? If "FP State" just means floating point register values then those rarely contain interesting stuff. If this also affects register used for crypto acceleration then it could be used for stuff like leaking browser secrets from javascript, right?

Rarely contain interesting stuff, like parts of AES keys.

Re: Intel SA-00145: Lazy FP State Restore

#37

Post by jcranmer »

vbezhenar wrote: post #24
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…

I wonder why do we have to rely on CPU to parallelize code. Surely compiler could do better job and CPU should just offer transistors without any smart logic. It's not backwards-compatible and I'm aware about Itanium fiasco, but I'm not compelled that it's a wrong way.

As someone who works in compilers: no, it's not possible to make the compiler do a better job. There's a reason why VLIW architectures keep getting proposed and keep dying.

The instruction-level parallelism that a CPU can extract is primarily a dynamic kind of parallelism. You can, say, have a branch that's true 1000 times, then false 1000 times, then true 1000 times, then false 1000 times, etc.--as a compiler, telling the hardware to predict true or false is going to guarantee a 50% hit rate, but the stupid simple dynamic branch predictor will get 99% on that branch.

Re: Intel SA-00145: Lazy FP State Restore

#38

Post by monocasa »

cperciva wrote: post #28
monocasa wrote: post #15

Earlier quoted context omitted.

Lazy context switching is a thing on pretty much every architecture with an FPU.

Hmm, I thought most RISCy CPUs kept FP values in GP registers?

No, I can't think of an arch that does that. Power, SH, Mips, Sparc, Alpha, ARM, and RISC-V all have separate architectural register files for the floating point state.

Some ARM ABIs end up passing floats in integer registers, but that's just for compatibility for code that doesn't assume the presence of an FPU and might be doing everything soft float.

Re: Intel SA-00145: Lazy FP State Restore

#39

Post by kinghajj »

jcranmer wrote: post #37
vbezhenar wrote: post #24

Earlier quoted context omitted.

I wonder why do we have to rely on CPU to parallelize code. Surely compiler could do better job and CPU should just offer transistors without any smart logic. It's not backwards-compatible and I'm aware about Itanium fiasco, but I'm not compelled that it's a wrong way.

As someone who works in compilers: no, it's not possible to make the compiler do a better job. There's a reason why VLIW architectures keep getting proposed and keep dying. The instruction-level parallelism that a CPU can extract is primarily a dynamic kind of parallelism. You can, say, have a branch that's true 1000 times, then false 1000 times, then true 1000 times, then false 1000 times, etc.--as a compiler, telli…

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

Re: Intel SA-00145: Lazy FP State Restore

#40

Post by cperciva »

monocasa wrote: post #38
cperciva wrote: post #28

Earlier quoted context omitted.

Hmm, I thought most RISCy CPUs kept FP values in GP registers?

No, I can't think of an arch that does that. Power, SH, Mips, Sparc, Alpha, ARM, and RISC-V all have separate architectural register files for the floating point state. Some ARM ABIs end up passing floats in integer registers, but that's just for compatibility for code that doesn't assume the presence of an FPU and might be doing everything soft float.

Hmm, ok. It's a long time since I've looked at that. Come to think of it, I think it might be 20 years since I opened CA:QA...
Post reply on HN