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

51–60 of 127 posts

Re: Intel SA-00145: Lazy FP State Restore

#51

Post by kentonv »

the8472 wrote: post #46
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…

> 2. The scalability of edge computing requires finer-grained isolation than process isolation. Why? Browsers are moving to one process per security domain anyway. Workers spawn their own threads too. You have to make your processes more lightweight and optimize memory-sharing, but that's exactly what's happening. There's also some vodoo one might be able to do on linux with the clone syscall which lets you spawn a n…

> Browsers are moving to one process per security domain anyway.

At a significant cost in RAM usage and some CPU overhead too. But browsers have the advantage that they are sitting on desktops and laptops that are massively underutilized, and the number of security domains you might typically have open at once is in the 10's or 100's, not 10,000's.

But that's not what I was talking about with "edge computing". I'm the architect of Cloudflare Workers, an edge compute platform. We have 151 locations today and are pushing towards thousands in the coming years, and every one of our customers wants their code to run in every location. As we push to more and more locations, the available resources in each location decrease, but the number of customers will only increase.

At our scale, unlike browsers, one-process-per-customer just isn't going to scale. Context switching is too expensive, RAM usage per process is too high, etc. So we need other ways to mitigate attacks.

> There's also some vodoo one might be able to do on linux with the clone syscall which lets you spawn a new process which still shares the same memory as the parent.

It's not really voodoo. Linux has no distinction between processes and threads. Everything is a process. But two processes can share the same memory space. Usually, developers call these "threads", and use "process" to mean "the set of threads sharing a memory space".

In any case, if it's the same memory space, then it's susceptible to Spectre attacks.

Re: Intel SA-00145: Lazy FP State Restore

#52

Post by caf »

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…

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?

Re: Intel SA-00145: Lazy FP State Restore

#53

Post by pera »

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-7 will automatically default to (safe) “eager” floating point register restore on Sandy Bridge and newer Intel processors. AMD processors are not affected.

https://access.redhat.com/solutions/3485131

Re: Intel SA-00145: Lazy FP State Restore

#54

Post by caf »

cperciva wrote: post #21
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?

"FP State" in this case includes MMX and SSE registers; they're handled via the same "lazy context switching" mechanism. Yes, you can steal keys which are being used for AESNI. Leaking secrets via javascript -- I'll be impressed if someone pulls that off. There's a very tight timing window to exploit this before a trap fires and flushes your pipeline, and I doubt you can get the right instructions in there using java…

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

Re: Intel SA-00145: Lazy FP State Restore

#55

Post by pcwalton »

the8472 wrote: post #46
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…

> 2. The scalability of edge computing requires finer-grained isolation than process isolation. Why? Browsers are moving to one process per security domain anyway. Workers spawn their own threads too. You have to make your processes more lightweight and optimize memory-sharing, but that's exactly what's happening. There's also some vodoo one might be able to do on linux with the clone syscall which lets you spawn a n…

There are limits to Site Isolation. For example, due to document.domain, subdomains of a domain cannot generally be protected from one another.

kentonv is correct that giving up on intra-process security entirely is an ominous sign.

Re: Intel SA-00145: Lazy FP State Restore

#56

Post by drb91 »

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…

From what I understand, speculative execution is “worth it” in most non secure contexts. Furthermore, it seems like one could hypothetically implement speculative execution “correctly”, where speculation is still gated by the constraints of non speculated executions. Could this be a problem that proof software could solve? I still have hope.

Re: Intel SA-00145: Lazy FP State Restore

#57

Post by Taniwha »

kinghajj wrote: post #39
jcranmer wrote: post #37

Earlier quoted context omitted.

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?

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 software scheduled CPUs allowed us to reach 20GHz clock speeds where complex superscalar machines were stuck at 3GHz we'd all be jumping ship - but they're not

Re: Intel SA-00145: Lazy FP State Restore

#58

Post by aseipp »

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…

Well, there are middle grounds, such as EDGE architectures, that get you somewhere in the middle of a VLIW and CISC machine, where everything is not so rigid. The trick isn't that the compiler must do better in scheduling things perfectly against unknown, dynamic information -- but must emit the information it already knows, and they currently throw away. This is how TRIPS worked, where the compiler placed instructions statically like a VLIW machine (it was a grid-like architecture, so this is obviously important), but the CPU issued instructions dynamically at the basic block level, like a OoO CISC machine. The secret is you encode the dataflow dependencies inside basic blocks, more or less -- so the CPU does not have to rediscover them.

I worked on compilers too, and I think there is definitely still work to be explored here. Really, complicated OoO speculative processors are simply recovering a lot of the information the compiler already calculated! You take this code that is in no way suited for a CPU, and you do a ton of dataflow and high-level analysis on it (that you can only know from the source). You build this graph and optimized based on these facts. And then, you throw away the dataflow graph when you lower things. All this, after painfully calculating it on the assumed basis of "Yes, the CPU will like this code" -- only for the CPU to perform that whole process over again, say "Yes, I do, in fact, like this code" -- so it can execute efficiently without stalls anyway. There's clearly a mismatch here.

I mean, don't get me wrong -- this all seems like a perfectly fine and acceptable engineering tradeoff, but just disappointing from a computer science perspective, to me, at least, that this is not unified :) Of course, VLIW vs CISC etc is one of the classic debates...

Interestingly, Aaron Smith from Microsoft Research (and one of the original members of the TRIPS project) actually demonstrated and talked about their work on newer EDGE processor designs at MSR, and even demonstrated Windows running on an EDGE processor, this past week or so at ISCA2018 (complete with a working Visual Studio target, using an LLVM-based toolchain!) Their design is quite different from TRIPS it seems. I'm hoping the talks/work becomes public eventually, but that might just be a dream.

Re: Intel SA-00145: Lazy FP State Restore

#59

Post by dnautics »

baobrien wrote: post #41
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.

Basically every CPU with a pipeline -- even simple, in-order cores -- speculate by way of branch prediction. I think with the Cortex A53 the pipeline is short enough and the branch predictor simple enough that you can't build a useful spectre attack. It's also common in simpler in-order cores to speculate a little bit around memory accesses.

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

Re: Intel SA-00145: Lazy FP State Restore

#60

Post by cperciva »

caf wrote: post #54
cperciva wrote: post #21

Earlier quoted context omitted.

"FP State" in this case includes MMX and SSE registers; they're handled via the same "lazy context switching" mechanism. Yes, you can steal keys which are being used for AESNI. Leaking secrets via javascript -- I'll be impressed if someone pulls that off. There's a very tight timing window to exploit this before a trap fires and flushes your pipeline, and I doubt you can get the right instructions in there using java…

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