Intel SA-00145: Lazy FP State Restore • Hacker News Board

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 the performance back through fixes on the cpu or will speculative execution always be insecure and thus need patching in software?

Try as I might, I am not a CPU person.

Re: Intel SA-00145: Lazy FP State Restore

#14

Post by techntoke » Wed, Jun 13, 2018, 10:58 PM UTC

kentonv wrote: post #10

Andy Lutomirski noted on another thread that he unintentionally fixed this two years ago in Linux: https://news.ycombinator.com/item?id=17304947 (He switched it to eager FP because it's faster on modern hardware.) But a lot of people running old LTS kernels may be affected. EDIT: Looks like Luto's change landed in kernel version 4.6. https://kernelnewbies.org/Linux_4.6#List_of_merges https://git.kernel.org/pub/scm/li…

Does that include Red Hat Enterprise Linux? I can't believe how old of a kernel they use still. I have to use it for work, but I run Arch at home which is running 4.16.13. I'm honestly surprised that Red Hat can't manage to keep their distros current with stable package builds.

Re: Intel SA-00145: Lazy FP State Restore

#15

Post by monocasa » Wed, Jun 13, 2018, 11:00 PM UTC

cperciva wrote: post #9

andreiw wrote: post #5

Do we have PoC code? Has anyone tried attacking FP/SIMD state on other ISAs like Power or AArch64?

I have exploit code -- took me about 5 hours to write after Theo announced all the important details of the vulnerability. I'm not going to publish it yet, though. AFAIK other systems aren't affected -- is lazy context switching even a thing on them? The fundamental issue here is that one process' data is still in registers when another process is running and we've been relying on getting a trap to tell us when we ne…

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

Re: Intel SA-00145: Lazy FP State Restore

#16

Post by shawnz » Wed, Jun 13, 2018, 11:01 PM UTC

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…

Personally I wonder if it will ever be possible to have a platform totally free of side-channel attacks, whether or not it uses speculative execution.

Re: Intel SA-00145: Lazy FP State Restore

#17

Post by kanox » Wed, Jun 13, 2018, 11:04 PM UTC

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?

Re: Intel SA-00145: Lazy FP State Restore

#18

Post by Tuna-Fish » Wed, Jun 13, 2018, 11:07 PM UTC

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 not fundamentally incompatible with security. It's just that literally everyone in the industry never though that leaking information out of speculative context was possible -- and so there is no hardening anywhere. Now that it was proven possible, people are rushing to find all the ways this can be exploited. New CPUs currently being designed will fix all these, and then eventually we will have speculation without security issues.

Except for Spectre variant 1. That will always stay with us, because there is no sensible fix for it. The only real solution to that is to accept that branches cannot be used as a security boundary. This is mostly relevant to people implementing secure sandboxes and language runtimes. 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. Any real security requires you to make use of the proper OS-provided isolation.

Re: Intel SA-00145: Lazy FP State Restore

#19

Post by gicmo » Wed, Jun 13, 2018, 11:09 PM UTC

techntoke wrote: post #14

kentonv wrote: post #10

Andy Lutomirski noted on another thread that he unintentionally fixed this two years ago in Linux: https://news.ycombinator.com/item?id=17304947 (He switched it to eager FP because it's faster on modern hardware.) But a lot of people running old LTS kernels may be affected. EDIT: Looks like Luto's change landed in kernel version 4.6. https://kernelnewbies.org/Linux_4.6#List_of_merges https://git.kernel.org/pub/scm/li…

Does that include Red Hat Enterprise Linux? I can't believe how old of a kernel they use still. I have to use it for work, but I run Arch at home which is running 4.16.13. I'm honestly surprised that Red Hat can't manage to keep their distros current with stable package builds.

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. :)

Re: Intel SA-00145: Lazy FP State Restore

#20

Post by snuxoll » Wed, Jun 13, 2018, 11:09 PM UTC

techntoke wrote: post #14

kentonv wrote: post #10

Andy Lutomirski noted on another thread that he unintentionally fixed this two years ago in Linux: https://news.ycombinator.com/item?id=17304947 (He switched it to eager FP because it's faster on modern hardware.) But a lot of people running old LTS kernels may be affected. EDIT: Looks like Luto's change landed in kernel version 4.6. https://kernelnewbies.org/Linux_4.6#List_of_merges https://git.kernel.org/pub/scm/li…

Does that include Red Hat Enterprise Linux? I can't believe how old of a kernel they use still. I have to use it for work, but I run Arch at home which is running 4.16.13. I'm honestly surprised that Red Hat can't manage to keep their distros current with stable package builds.

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 (oh VMWare, how I hate you so).