3 ms·

> wasm is also going that direction Genuine question: why would WASM in the kernel make any sense at all?

by twtw 8y ago

nicoburns 8y ago
Security. WASM is sandboxed by design.
- twtw 8y ago
  Many things are "sandboxed by design." Few things are true sandboxes. I'm very skeptical of the idea of throwing out virtual memory and process isolation to depend instead only on software sandboxes.
- jillesvangurp 8y ago
  That and performance. System calls have a lot of overhead when running in user space. You can dodge that when running as part of the kernel.
ordu 8y ago
It is incapsulation of code into a sandbox. You can do it by moving code into user-space and use hardware implemented sandbox, or you can do it by making your own sandbox in software. Hardware implementation runs code faster (kind of "executes more instructions per second"), but switching from user-space into kernel-space and back are costly. The costs are very high, high enough to projects like "user-space TCP/IP stack" start popping up: it is all about avoiding switching to and from kernel-mode. Software implementation of sandbox in the kernel allow costless (or near costless) switching of context, but runs slower. It is tradeoffs, and not every one piece of software would benefit from moving into kernel-WASM, but some would do.
drbawb 8y ago
It's sometimes useful to run "arbitrary" code in the context of the kernel. For a concrete example look at the Berkley Packet Filter[1]. In it's original usecase it allows packet filter expressions to get compiled into a bytecode, which in turn get verified & executed in a kernel-space virtual machine. This is useful because it allows the user to implement arbitrary expressions, in this case firewall rules, but have them executed in the context of the kernel. When you're trying to filter millions of packets per second, or instrument operations that are measured in sub-microseconds, avoiding that context switch matters. [1]: http://www.brendangregg.com/ebpf.html http://www.brendangregg.com/ebpf.html

> wasm is also going that direction Genuine question: why would WASM in the kernel make any sense at all?

by twtw 8y ago

> wasm is also going that direction Genuine question: why would WASM in the kernel make any sense at all?

nicoburns 8y ago

Security. WASM is sandboxed by design.

twtw 8y ago
Many things are "sandboxed by design." Few things are true sandboxes. I'm very skeptical of the idea of throwing out virtual memory and process isolation to depend instead only on software sandboxes.
jillesvangurp 8y ago
That and performance. System calls have a lot of overhead when running in user space. You can dodge that when running as part of the kernel.

ordu 8y ago

It is incapsulation of code into a sandbox. You can do it by moving code into user-space and use hardware implemented sandbox, or you can do it by making your own sandbox in software. Hardware implementation runs code faster (kind of "executes more instructions per second"), but switching from user-space into kernel-space and back are costly. The costs are very high, high enough to projects like "user-space TCP/IP stack" start popping up: it is all about avoiding switching to and from kernel-mode. Software implementation of sandbox in the kernel allow costless (or near costless) switching of context, but runs slower. It is tradeoffs, and not every one piece of software would benefit from moving into kernel-WASM, but some would do.

drbawb 8y ago

It's sometimes useful to run "arbitrary" code in the context of the kernel. For a concrete example look at the Berkley Packet Filter[1]. In it's original usecase it allows packet filter expressions to get compiled into a bytecode, which in turn get verified & executed in a kernel-space virtual machine. This is useful because it allows the user to implement arbitrary expressions, in this case firewall rules, but have them executed in the context of the kernel. When you're trying to filter millions of packets per second, or instrument operations that are measured in sub-microseconds, avoiding that context switch matters. [1]: http://www.brendangregg.com/ebpf.html http://www.brendangregg.com/ebpf.html