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

121–127 of 127 posts

Re: Intel SA-00145: Lazy FP State Restore

#121

Post by slrz »

techntoke wrote: post #120
burb_xry wrote: post #100

Earlier quoted context omitted.

The problem with that is that I'd argue it is "safer" to run a kernel.org stable kernel rather than RHEL, since it's sheer impossible to keep up with the amount of fixes that eventually land in stable kernels every few weeks. And it is unclear which of the stable fixes are security relevant ones even if they did not get a CVE number and the like. QAing all these is another mammoth task that often requires expertise i…

Right.. it's like they haven't managed to automate a CI pipeline to handle these changes for them. Other distros do it just fine, and I've had far more things break in CentOS or Red Hat than Arch.

That CI pipeline would need to be placed not at Red Hat but at their big customers and their hardware vendors. To RH's benefit, those tend to suck at that and prefer to pay big dollars over having to keep up with kernel development or getting rid of their crappy out-of-tree drivers.

If you have the appropriate CI pipelines as well as the kind of developers capable of directly consuming the upstream community outputs, by all means, do that. Many companies aren't like that though and prefer talking to tech support people over diving into the source code themselves. I guess we should just be happy about the fact that they fund Linux development at Red Hat.

Re: Intel SA-00145: Lazy FP State Restore

#122

Post by kentonv »

mwcampbell wrote: post #106
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…

On JavaScript being a secure sub-process sandbox, as my manager told me months before Spectre, "Pwn2Own says otherwise." Much to my disappointment.

JavaScript is the most secure we have. The fact that it is subject to Pwn2Own is part of why. Other sandboxes have not received anywhere near the scrutiny, and surely have many more bugs that simply haven't been found.

Process, container, and VM isolation all have lots of bugs too.

Re: Intel SA-00145: Lazy FP State Restore

#123

Post by gpderetta »

pcwalton wrote: post #55
the8472 wrote: post #46

Earlier quoted context omitted.

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

What we need is the equivalent of inter process isolation for intraprocess sandboxes, i.e. an hardware solution (hopefully this time not affected by Meltdown).

And we might already have it. Thanks to virtualization hardware, it should be possible for a process to own and handle its own private page table mapping completely from userspace [1].

Switching from the sandboxed code to the sandboxing code might be more expensive than a plain function call, but still way faster than IPC.

[1] For example, libDune (https://github.com/ramonza/dune), which admittedly seems a dead project. Also it requires OS support.

Re: Intel SA-00145: Lazy FP State Restore

#124

Post by lathiat »

kbenson wrote: post #117
kevin_thibedeau wrote: post #107

Earlier quoted context omitted.

How is that not a GPL violation?

The source code is released, it's just the formatting that has changed. Presumably the contract is around the extra effort RedHat puts into making the source nice and easily manageable by providing what they used to by default, a pristine kernal and a bunch of patches to apply. The normal method now is that they provide a large, pre-patches kernel source, which is then built. In both cases, the same code source is us…

Oracle then started a project to break them back out again. Last update seems to be November 2017 though.

https://oss.oracle.com/projects/RedPatch/

Re: Intel SA-00145: Lazy FP State Restore

#125

Post by mwcampbell »

kentonv wrote: post #122
mwcampbell wrote: post #106

Earlier quoted context omitted.

On JavaScript being a secure sub-process sandbox, as my manager told me months before Spectre, "Pwn2Own says otherwise." Much to my disappointment.

JavaScript is the most secure we have. The fact that it is subject to Pwn2Own is part of why. Other sandboxes have not received anywhere near the scrutiny, and surely have many more bugs that simply haven't been found. Process, container, and VM isolation all have lots of bugs too.

Do you think it's likely, though, that a language-based sandbox is more secure than a process-based sandbox? Every major browser developer has now embraced process-based sandboxing in addition to the JavaScript sandbox they already had. Believe me, I want sub-process sandboxing to be viable. But now, post-Spectre, I think it's hopeless.

Re: Intel SA-00145: Lazy FP State Restore

#126

Post by 0x0 »

maurom wrote: post #12
0x0 wrote: post #2

Status in Debian: https://security-tracker.debian.org/tracker/CVE-2018-3665

Just what I was looking for. Guess we'll get a new security announce. Thanks

... for debian 8 only, though. Looks like current stable dodged that bullet quite a while ago.

Re: Intel SA-00145: Lazy FP State Restore

#127

Post by kentonv »

mwcampbell wrote: post #125
kentonv wrote: post #122

Earlier quoted context omitted.

JavaScript is the most secure we have. The fact that it is subject to Pwn2Own is part of why. Other sandboxes have not received anywhere near the scrutiny, and surely have many more bugs that simply haven't been found. Process, container, and VM isolation all have lots of bugs too.

Do you think it's likely, though, that a language-based sandbox is more secure than a process-based sandbox? Every major browser developer has now embraced process-based sandboxing in addition to the JavaScript sandbox they already had. Believe me, I want sub-process sandboxing to be viable. But now, post-Spectre, I think it's hopeless.

The combination of language-based sandboxing and process-based sandboxing is, of course, more secure than either on its own. More layers can only help. You could go a step further and run the process sandbox inside a VM. And run that VM on a dedicated machine. Each layer helps -- but each layer is more expensive, and at some point the cost is too high.

But process-based sandboxing does not replace language-based sandboxing. Operating systems (e.g. Linux) have bugs all the time that allow processes to escalate privileges. It's also not at all clear that process-based sandboxing is enough to defend against spectre, either. But it's much harder to design an attack than can break both layers, than to design one that breaks one or the other.

Certainly, if process-based sandboxing does not add too much overhead for your use case, then you absolutely should use it in addition to language-based sandboxing. But there are plenty of use cases where processes are too much overhead and we really need language-based sandboxing to make progress.

Post reply on HN