Hacker News Reader

Comment by IncRnd | Hacker News Reader

> Normally, this would be super dangerous, but WebAssembly is designed to run safely on remote computers, so it can be securely sandboxed without losing performance.

This throws away the very important security property of defense in depth. A system design should include interlocking levels of security, so even if there is a vulnerability in one place, extra work may be required to exploit it.

View on HN

I agree with you for the most part here. For the things that I typically use computers for, I would prefer to have both hardware and software protected sandboxes. There's a reason that browsers are switching to using multiple processes.

I suspect you are being downvoted for being overly emphatic. I can certainly think of scenarios where having this extra security is more costly than helpful.

An interesting point of note is that the mill architecture has been designed to have much cheaper hardware protection than other architectures. [1]

[1] https://www.youtube.com/watch?v=5osiYZV8n3U

It's no worse than what Linux already allows via eBPF.

Is a packet filter really as complex and with as much room for error as a WASM VM?

BPF isn't just a packet filter. It's a JIT VM.

This started back in 2011 with https://lwn.net/Articles/437981/

It's since been extended quite a bit from even that, and can be used for a variety of things, including dynamic tracing (BCC is an excellent frontend here), processing beyond just filtering (XDP), and more. https://lwn.net/Articles/740157/

It might be less complex than the WASM VM, but it's quite a bit beyond just a packet filter these days.

So? Removing hw ring protections for all programs is not the answer.

You are actually making my point.

Hardware protection rings are a holdover from a time when we didn't have program formats that could be statically transformed and verified to do exactly what the operator desires. They have a nonzero performance overhead even when implemented in hardware, and in an ideal design should not be required at all

Re: your followup about defensive in depth, this is a common and frankly boring fallback argument. At some point computers had much less reliable internals, and for example even the result of strlen () could vary across runs. Should we also perpetually account for the presence of unreliable registers or memory too?

> when we didn't have program formats that could be statically transformed and verified to do exactly what the operator desires.

Which we still don't. Rowhammer, spectre/meltdown, etc... proved that even if the code doesn't violate any sandbox constraints that doesn't mean it didn't violate everything the sandbox was attempting to protect.

Hardware isolation is still very important and very necessary, now more than ever.

JFC. The reason the bugs you refer to are so important is because they /spanned/ hardware protection domains.

Yes, which means they also spanned software protection domains. Meaning your software protection didn't work, regardless of how "verifiable" the bytecode is.

And a few of those so far have no known software protection domain fix, relying instead of hardware domains (eg spectre, which is why Chrome pushing site isolation hard - because they can't fix the software protection and are relying on hardware ones instead)

That doesn't apply to this discussion. What program verification or analysis were performed on this system?

My position about defense in depth is not a fallback argument. It was my original point.

Is your position that Linux should remove eBPF?

That's not germane to this discussion. My position is that this project throws away defense in depth.

Is your point that because eBPF exists in a different OS that there is no security impact to using Nebulet?

I think that having a user-accessible VM in the kernel is a useful thing that a lot of OS's eventually need for other reasons (e.g. packet filtering, syscall sandboxing). We might as well design for it properly up front.

Thank you for bringing that up. That's an entirely different discussion, and one that I agree is valid to have. Though, I really don't see the need for user space programs to be able to insert executable code into kernel memory, when hw ring protections would otherwise be in use. Maybe if there were already a verified set of interlocking software controls, then hw protections could be replaced, but I don't see that with running all wasm in the kernel space.

Reply on news.ycombinator.com