13 ms·

Wasmjit: Kernel Mode WebAssembly Runtime for Linux

214 points by varenc 8y ago

merlincorey 8y ago
My mind boggles at the meta-ness of using this software to (direct from the docs) speed up the operation of a webserver compiled to webassembly. The paranoid security engineer in me screams "Ring0 is what I always wanted my browser to have access to". Interesting project!
- comesee 8y ago
  Upon inspection of the code, it seems like this is something that could be used by browsers as well...
- quickben 8y ago
  Do not worry, it will be secure. Signed, with verifiable checksums, and gdrp friendly. Just, erm, load these binaries provided by FB, Google, Microsoft and Netflix. :P
- TrueDuality 8y ago
  My first thought was mental yelling about keeping kids out of my kernel space. It's been a couple minutes and that has settled down to a grumbling about people sacrificing security in the name of performance again.
yissp 8y ago
Prescient https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
- wcrichton 8y ago
  Except, WebAssembly isn't even close to Javascript. They're completely different languages. WebAssembly is closer to C than to Javascript.
  - jchw 8y ago
    On the surface level, sure. However, it's mostly just a lower abstraction way of accessing largely the same JIT. I'm pretty sure browsers supporting WebAssembly are doing so by reusing most of what they already have. And if you dig deeper, this was almost certainly inspired by tools like Emscripten and the Asm.js concept. After all, Asm.js accomplished a similar goal to WebAssembly, at the end of the day; Wasm is a cleaner, higher performance, less backwards compatible way of doing largely the same thing. JS already unhinged from the browser pretty thoroughly. I think when it comes to Wasm it's almost as much about what it doesn't have as what it does have. Lack of DOM bindings and a GC make it much more suitable for hosting in more environments like the kernel.
  - gtremper 8y ago
    WebAssembly is basically just a binary encoding of asmjs, which is the subset of javascript discussed in the talk.
    - panic 8y ago
      WebAssembly is a statically-typed language which passes values around using a stack. It’s very different from asm.js.
    - callahad 8y ago
      While asm.js was basically just a textual encoding of C in JavaScript... round and round we go! :)
      - gtremper 8y ago
        I'd say it more a textual encoding of LLVM IR. Which makes the s-expression text format of WebAssembly a text encoding of a binary encoding of a javascript encoding of a compiler intermediate representation of your program. Round and round indeed.
    - shawnz 8y ago
      Yeah, but it doesn't have "Javascript" in the name, which makes it automatically better by way of bypassing everyone's irrational hatred of JS
- IshKebab 8y ago
  Not really, it was what everyone was hoping would happen for ages. Remember PNaCl?
joshumax 8y ago
I stumbled across WasmJIT about a year ago and actually used many of the concepts in the project for my own kernelspace implementation of the portable native client (pNaCl). Projects like these are extremely interesting to me because they offer the possibility of a completely architecture-neutral userspace that can be used across multiple devices without recompilation.
- infogulch 8y ago
  This goes a step further and could offer an architecture-neutral kernel space. If part of loading the module includes validation and external memory access is checked as in browser implementations this could even lead to safer/less exploitable kernel modules with more well-defined failure modes.
  - ChickeNES 8y ago
    The problem I see with this is that there are still no 8bit or 16bit data types (or bitfields for that matter) in the wasm spec, which are kind of useful for interfacing with hardware and for protocols (Ethernet, TCP/IP, etc). Sure, you can pack and unpack them with masks and shifts (which I assume clang,LLVM,gcc,etc do), but it seems awfully inefficient when the resulting code ends up running on x86 or other architectures with native 8/16 bit instructions.
    - josephg 8y ago
      Unless I'm missing something, this should be pretty easy for the webassembly working group to fix. At a guess they probably just need some clear decisions around how to handle endian issues. But right now they're just focussing on the browser use case. If kernel module developers become a vocal part of the wasm ecosystem, I'd expect 8- and 16- bit data types to get added before long.
      - infogulch 8y ago
        I wonder if the pattern is common enough and simple enough that wasmjit could substitute the load-shift-and/shift-or-store sequences into direct 8,16,32-bit stores and loads.
kettlecorn 8y ago
Increasingly I’m becoming convinced that something like this may become the backbone of future computing. Imagine truly cross platform code that performs well, and can be written in whatever language you care for. The web illustrated certain advantages to developing software that can be easily delivered and run on other systems. However, the learnings of the web were always coupled to the browser. WebAssembly, through projects like this, may soon be able to empower cross platform code that delivers small, well performing programs on whatever platform a user desires to use.
- zimablue 8y ago
  Genuinely ignorant question, what's the difference with C from this perspective? I thought the whole point of C was to be a common language.
  - kodablah 8y ago
    Nasal demons
  - naasking 8y ago
    Binary compatibility across architectures, no undefined behaviours are the primary ones.
    - quickben 8y ago
      Yes of course, here is an example of a well defined, no ub, == overloads. https://slikts.github.io/js-equality-game/ https://slikts.github.io/js-equality-game/ It is all bound to make JS kernel programing a Pilar of OS Stability.
      - kanox 8y ago
        Does that apply to web assembly?
      - tomjakubowski 8y ago
        None of that applies to web assembly, as I'm sure you know.
snaky 8y ago
"Lua support in the NetBSD kernel" (2013) https://news.ycombinator.com/item?id=6562611 https://news.ycombinator.com/item?id=6562611
- gnufx 8y ago
  Long ago someone stuffed a Scheme(-ish?) interpreter into Linux, but I don't think it went anywhere. I forget the details, but it may have used the SIOD implementation. I'd prefer it in a microkernel's userspace, though...
muricula 8y ago
This neuters a bunch of the new spectre and meltdown mitigations which are required if you want ring 0 to be a security boundary.
- comesee 8y ago
  How so? WebAssembly can't address memory outside of its sandbox
  - BeeOnRope 8y ago
    The whole point of Spectre is that you can indirectly access memory outside of your "sandbox" even if you don't have permissions to those pages, using various side channels.
    - comesee 8y ago
      Aren't those side channels dependent on addressing kernel memory that you don't have permissions for? You can't address kernel memory in WebAssembly, therefore you can't provoke the speculator into caching those pages.
      - hinkley 8y ago
        Oh my sweet summer child. You don’t need to use one exploit if two that interact are common enough. How about a nice pointer arithmetic bug in any reasonably common version of the webasm runtime?
        TomMarius 8y ago
        Let's assume that the runtime is bugless. What security concerns would be still there, and why?
      - dbaupp 8y ago
        I believe Spectre is driven by processor speculation into a bounds-checked array access, even for when the condition fails (that is, the index is out of bounds). One can get to arbitrary memory in this way using the right index on any array.
JepZ 8y ago
Does anybody know if that kernel module can execute WASM generated from Go or Rust too?
- steveklabnik 8y ago
  Unless they’re doing something non-standard, wasm doesn’t care what language it came from. That said, this claims it relies on emscripten, I think? You can do that with Rust, though it’s not the preferred way. I sure about Go.
  - comesee 8y ago
    From looking at high_level.h it can instantiate any wasm file, but it seems to need the host code specially integrated. There is a function to instantiate the emscripten runtime, probably code can be added to instantiate the go or rust runtimes.
    - steveklabnik 8y ago
      Rust doesn’t have a runtime. Well, at least not in the sense of other languages; it’s comparable to C :) Emscripten provides a libc; I wondered if it required it. I guess not.
      - lloeki 8y ago
        > it’s comparable to C I think you may want to reassess your definition of what a runtime is ;) > "crt" stands for "C runtime", and the zero stands for "the very beginning". [ https://en.wikipedia.org/wiki/Crt0 https://en.wikipedia.org/wiki/Crt0 | https://en.wikipedia.org/wiki/Runtime_library https://en.wikipedia.org/wiki/Runtime_library ] Yup. C definitely has a runtime!
        steveklabnik 8y ago
        That’s why I said that Rust’s is comparable to C. Both have very, very small ones. Which is what most people mean when they say “no runtime”, since every non-assembly language has some amount of runtime.
ncmncm 8y ago
The actual problem with this, after you have satisfied yourself about the numerous non-problems, is that practically any real app in wasm has calls to library code implemented in C or C++ and compiled to real asm to implement the extended Javascript runtime, that you would not want running in ring 0. To those are added all the kernel-mode functions that must be used correctly. (If the app can be provoked to use them wrong, boom.) So, the plausible use is an implicitly trusted app not exposed to untrusted input, that is system-call bound, and that you want to distribute cross-platform without recompiling to targets that have installed this module in a known kernel version. It seems easier just to distribute source for a kernel module; or kernel modules built for the (2? 3 tops) architectures required. [edit: spelling error.]
- _wmd 8y ago
  I'm not sure why linking third party code is a concern, it all must live inside the sandbox provided by the runtime. This reduces the trust requirements from depending on a (software | hardware) solution where the hardware portion cannot be audited, and by 2018 are no longer to be considered trustworthy by default, to only depending on access and bounds checks implemented by a single body of code visible to everyone. The 'system call interface' available to those buggy libraries need be no more capable than existed previously, that system calls are serviced without switching protection mode need not extend the potency of any possible attacks. A future implementation of this style of design will have much better security and auditability properties than anything that has ever popularly existed in the past. It may have originated with the web, but I welcome wasm and all the market punch it promises to bear on ancient and long-unquestioned corners of our software stack like this. (Naturally I was also a Microsoft Singularity fan)
  - deathanatos 8y ago
    How does WebAssembly fix hardware issues? For example, take Rowhammer. I don't see how running your code in a VM fixes Rowhammer; surely there would still be some mapping of data in wasm to RAM, and I don't see why a sufficiently motivated individual couldn't determine and subsequently exploit that mapping. Or what does WASM do about the concerns that major CPU vendors embed a second co-processor running untrusted, unauditable code with ring -1 access alongside the main CPU?¹ ¹which may or may not be active, depending on CPU model and configuration. I've never really fully understood when it is, or isn't, but I think it's somewhat moot. Further, this assumes the runtime (which is not just the WASM runtime: system calls and other functionality will inevitably need access to the actual, underlying hardware in order to do their job) from being buggy, and since the code is now in ring 0, you get all the consequences of that. (Full, unrestricted access to everything. At least previously, you'd need to find some root exploit to get that.) (Also, as another poster hints below, since everything is running inside the same protection layer from the CPU's point of view, what prevents you from just running the same attack, in spirit, as Spectre? Only now, there is no protection — everything is ring 0 — so the CPU is "correct" to speculate a read. Sure, the VM will deny it to the code inside the VM, but that didn't matter in the case of Spectre?)
uluyol 8y ago
Serious question: what's the advantage of something like this over eBPF? As I understand it, you can generate eBPF bytecode from C and Linux already has a JIT compiler for it.
- telotortium 8y ago
  eBPF is a limited, non-Turing complete language, in particular not having loops. Because of this, it's feasible to allow users to upload eBPF filters into the kernel, because execution is safe and and the time to run the filter can be upper-bounded. Wasm, on the other hand, is a memory-safe interpreter, but unlike eBPR is Turing-complete, so it can run arbitrary programs.
  - snaky 8y ago
    > in particular not having loops Well, almost. > The main object of this patch series is to support verification of eBPF programs with bounded loops. Only bounds derived from JLT (unsigned <) with the taken branch in the loop are supported, but it should be clear how others could be added. https://lwn.net/Articles/748032/ https://lwn.net/Articles/748032/
- kbumsik 8y ago
  Many other modern languages such as Rust and Go are aiming to officially support WASM. I don't know much about eBPF but it looks like it only support C for now.
  - steveklabnik 8y ago
    A company just announced some cool eBPF and Rust stuff today: https://blog.redsift.com/labs/ebpf-ingrained-in-rust/ https://blog.redsift.com/labs/ebpf-ingrained-in-rust/
  - ncmncm 8y ago
    eBPF is generated from LLVM IR, so any language that compiles to IR works, so long as the code doesn't translate to IR operations not permitted in eBPF.
lachlan-sneff 8y ago
nebulet is an implementation of a similar idea, but on a different scale. https://github.com/nebulet/nebulet https://github.com/nebulet/nebulet
- moosingin3space 8y ago
  How has the work on Nebulet's IPC layer progressed? In theory, a kernel-mode wasm interpreter could make IPC as fast as calling a function in a shared library through a vtable. Of course, this has to be mediated properly to avoid letting processes mess with each others' memory!
  - lachlan-sneff 8y ago
    Slowly. I've been quite busy with school. What little time I have spent on nebulet has been on the fledgling network stack.
    - moosingin3space 8y ago
      I see. I'm excited about nebulet and would be interested in participating in the design process for the IPC layer -- is there a place that discussion is taking place?
      - lachlan-sneff 8y ago
        Yeah, totally! The gitter is where most conversations about this take place: https://gitter.im/nebulet/nebulet https://gitter.im/nebulet/nebulet
saurik 8y ago
I have seen at least three projects to run WebAssembly in the kernel, but not a single strong attempt at a good userland binary format for WebAssembly: I don't want to run WebAssembly in my kernel, I just want an architecture agnostic binary format for Linux executables.
- comesee 8y ago
  Emscripten seems like a good start, the tooling already exists.
- AnIdiotOnTheNet 8y ago
  Actually, you kinda already have it via QEMU, which is capable of doing syscall translation. Just compile your code for linux on any of the supported target archs and use QEMU User Mode Emulation to launch it.
- nwmcsween 8y ago
  I don't even think ELF can be architecture agnostic without doing some hideous hacks (aka 'fat' binaries).
  - IshKebab 8y ago
    It can because you'd just add Wasm as a new machine type. That would be intrinsically architecture-independent because... it is.
- JoshTriplett 8y ago
  > I just want an architecture agnostic binary format for Linux executables. What would you use that for, if you had it?
  - IshKebab 8y ago
    So you don't have to make different binaries for different architectures? Pretty obvious I would have thought.
  - pjmlp 8y ago
justinclift 8y ago
Related to this, the wasm generated by Go is currently tied to being executed in the browser. There doesn't yet seem to be a implementable standard to define what a non-browser execution environment looks like. The beginnings of a common spec are here though, which some places have started working with: https://github.com/CommonWA/cwa-spec https://github.com/CommonWA/cwa-spec That'll likely need to make it's way into the official specs: * https://github.com/WebAssembly/design https://github.com/WebAssembly/design * https://github.com/WebAssembly/spec https://github.com/WebAssembly/spec At which point implementations will have something to focus on. :) For the Go, this is the (recent) matching issue: https://github.com/golang/go/issues/27766 https://github.com/golang/go/issues/27766 Kind of guessing it'll turn into a tracking issue to get it done.
TimTheTinker 8y ago
Another step towards Metal[0] becoming a reality. [0] A (half) joke from Gary Bernhardt's excellent The Birth and Death of JavaScript (pronounced "yavascript"): https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
ArtWomb 8y ago
>>> results in a significant performance increase for syscall-bound programs like web servers Reminds me of "Why we use the kernel's TCP stack"? And eternal debate over the performance benefits of "kernel bypass" and "zero-copy" technologies such as DPDK versus full userspace TCP implementations like OpenOnload. https://blog.cloudflare.com/why-we-use-the-linux-kernels-tcp-stack/ https://blog.cloudflare.com/why-we-use-the-linux-kernels-tcp... Conclusion is that the untapped fruit in kernel TCP gains comes from tuning performance of the network stack itself: optimizing overhead a packet incurs on its path through the stack. A very active area of development. Netdev 0x13, THE Technical Conference on Linux Networking https://netdevconf.org/0x13/ https://netdevconf.org/0x13/
- snaky 8y ago
  The recent work on AF_XDP seems like it could became established middleground sweet spot almost as efficient as kernel bypass and userspace networking.
elcritch 8y ago
Fascinating concept! Wouldn’t this pause/block the kernel while the module runs? Can’t find anything in the readme. I always assumed kernel modules had to behave politely in terms of returning and not running indefinitely.
gigatexal 8y ago
I’ll keep all my apps if possible in user space please. Call me paranoid.
deleted 8y ago
[deleted]
_pmf_ 8y ago
Finally, full stack engineers live up to their title.

214 points by varenc 8y ago

My mind boggles at the meta-ness of using this software to (direct from the docs) speed up the operation of a webserver compiled to webassembly. The paranoid security engineer in me screams "Ring0 is what I always wanted my browser to have access to". Interesting project!

comesee 8y ago
Upon inspection of the code, it seems like this is something that could be used by browsers as well...
quickben 8y ago
Do not worry, it will be secure. Signed, with verifiable checksums, and gdrp friendly. Just, erm, load these binaries provided by FB, Google, Microsoft and Netflix. :P
TrueDuality 8y ago
My first thought was mental yelling about keeping kids out of my kernel space. It's been a couple minutes and that has settled down to a grumbling about people sacrificing security in the name of performance again.

yissp 8y ago

Prescient https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

wcrichton 8y ago
Except, WebAssembly isn't even close to Javascript. They're completely different languages. WebAssembly is closer to C than to Javascript.
- jchw 8y ago
  On the surface level, sure. However, it's mostly just a lower abstraction way of accessing largely the same JIT. I'm pretty sure browsers supporting WebAssembly are doing so by reusing most of what they already have. And if you dig deeper, this was almost certainly inspired by tools like Emscripten and the Asm.js concept. After all, Asm.js accomplished a similar goal to WebAssembly, at the end of the day; Wasm is a cleaner, higher performance, less backwards compatible way of doing largely the same thing. JS already unhinged from the browser pretty thoroughly. I think when it comes to Wasm it's almost as much about what it doesn't have as what it does have. Lack of DOM bindings and a GC make it much more suitable for hosting in more environments like the kernel.
- gtremper 8y ago
  WebAssembly is basically just a binary encoding of asmjs, which is the subset of javascript discussed in the talk.
  - panic 8y ago
    WebAssembly is a statically-typed language which passes values around using a stack. It’s very different from asm.js.
  - callahad 8y ago
    While asm.js was basically just a textual encoding of C in JavaScript... round and round we go! :)
    - gtremper 8y ago
      I'd say it more a textual encoding of LLVM IR. Which makes the s-expression text format of WebAssembly a text encoding of a binary encoding of a javascript encoding of a compiler intermediate representation of your program. Round and round indeed.
  - shawnz 8y ago
    Yeah, but it doesn't have "Javascript" in the name, which makes it automatically better by way of bypassing everyone's irrational hatred of JS
IshKebab 8y ago
Not really, it was what everyone was hoping would happen for ages. Remember PNaCl?

joshumax 8y ago

I stumbled across WasmJIT about a year ago and actually used many of the concepts in the project for my own kernelspace implementation of the portable native client (pNaCl). Projects like these are extremely interesting to me because they offer the possibility of a completely architecture-neutral userspace that can be used across multiple devices without recompilation.

infogulch 8y ago
This goes a step further and could offer an architecture-neutral kernel space. If part of loading the module includes validation and external memory access is checked as in browser implementations this could even lead to safer/less exploitable kernel modules with more well-defined failure modes.
- ChickeNES 8y ago
  The problem I see with this is that there are still no 8bit or 16bit data types (or bitfields for that matter) in the wasm spec, which are kind of useful for interfacing with hardware and for protocols (Ethernet, TCP/IP, etc). Sure, you can pack and unpack them with masks and shifts (which I assume clang,LLVM,gcc,etc do), but it seems awfully inefficient when the resulting code ends up running on x86 or other architectures with native 8/16 bit instructions.
  - josephg 8y ago
    Unless I'm missing something, this should be pretty easy for the webassembly working group to fix. At a guess they probably just need some clear decisions around how to handle endian issues. But right now they're just focussing on the browser use case. If kernel module developers become a vocal part of the wasm ecosystem, I'd expect 8- and 16- bit data types to get added before long.
    - infogulch 8y ago
      I wonder if the pattern is common enough and simple enough that wasmjit could substitute the load-shift-and/shift-or-store sequences into direct 8,16,32-bit stores and loads.

kettlecorn 8y ago

Increasingly I’m becoming convinced that something like this may become the backbone of future computing. Imagine truly cross platform code that performs well, and can be written in whatever language you care for. The web illustrated certain advantages to developing software that can be easily delivered and run on other systems. However, the learnings of the web were always coupled to the browser. WebAssembly, through projects like this, may soon be able to empower cross platform code that delivers small, well performing programs on whatever platform a user desires to use.

zimablue 8y ago
Genuinely ignorant question, what's the difference with C from this perspective? I thought the whole point of C was to be a common language.
- kodablah 8y ago
  Nasal demons
- naasking 8y ago
  Binary compatibility across architectures, no undefined behaviours are the primary ones.
  - quickben 8y ago
    Yes of course, here is an example of a well defined, no ub, == overloads. https://slikts.github.io/js-equality-game/ https://slikts.github.io/js-equality-game/ It is all bound to make JS kernel programing a Pilar of OS Stability.
    - kanox 8y ago
      Does that apply to web assembly?
    - tomjakubowski 8y ago
      None of that applies to web assembly, as I'm sure you know.

snaky 8y ago

"Lua support in the NetBSD kernel" (2013) https://news.ycombinator.com/item?id=6562611 https://news.ycombinator.com/item?id=6562611

gnufx 8y ago
Long ago someone stuffed a Scheme(-ish?) interpreter into Linux, but I don't think it went anywhere. I forget the details, but it may have used the SIOD implementation. I'd prefer it in a microkernel's userspace, though...

muricula 8y ago

This neuters a bunch of the new spectre and meltdown mitigations which are required if you want ring 0 to be a security boundary.

comesee 8y ago
How so? WebAssembly can't address memory outside of its sandbox
- BeeOnRope 8y ago
  The whole point of Spectre is that you can indirectly access memory outside of your "sandbox" even if you don't have permissions to those pages, using various side channels.
  - comesee 8y ago
    Aren't those side channels dependent on addressing kernel memory that you don't have permissions for? You can't address kernel memory in WebAssembly, therefore you can't provoke the speculator into caching those pages.
    - hinkley 8y ago
      Oh my sweet summer child. You don’t need to use one exploit if two that interact are common enough. How about a nice pointer arithmetic bug in any reasonably common version of the webasm runtime?
      - TomMarius 8y ago
        Let's assume that the runtime is bugless. What security concerns would be still there, and why?
    - dbaupp 8y ago
      I believe Spectre is driven by processor speculation into a bounds-checked array access, even for when the condition fails (that is, the index is out of bounds). One can get to arbitrary memory in this way using the right index on any array.

JepZ 8y ago

Does anybody know if that kernel module can execute WASM generated from Go or Rust too?

steveklabnik 8y ago
Unless they’re doing something non-standard, wasm doesn’t care what language it came from. That said, this claims it relies on emscripten, I think? You can do that with Rust, though it’s not the preferred way. I sure about Go.
- comesee 8y ago
  From looking at high_level.h it can instantiate any wasm file, but it seems to need the host code specially integrated. There is a function to instantiate the emscripten runtime, probably code can be added to instantiate the go or rust runtimes.
  - steveklabnik 8y ago
    Rust doesn’t have a runtime. Well, at least not in the sense of other languages; it’s comparable to C :) Emscripten provides a libc; I wondered if it required it. I guess not.
    - lloeki 8y ago
      > it’s comparable to C I think you may want to reassess your definition of what a runtime is ;) > "crt" stands for "C runtime", and the zero stands for "the very beginning". [ https://en.wikipedia.org/wiki/Crt0 https://en.wikipedia.org/wiki/Crt0 | https://en.wikipedia.org/wiki/Runtime_library https://en.wikipedia.org/wiki/Runtime_library ] Yup. C definitely has a runtime!
      - steveklabnik 8y ago
        That’s why I said that Rust’s is comparable to C. Both have very, very small ones. Which is what most people mean when they say “no runtime”, since every non-assembly language has some amount of runtime.

ncmncm 8y ago

The actual problem with this, after you have satisfied yourself about the numerous non-problems, is that practically any real app in wasm has calls to library code implemented in C or C++ and compiled to real asm to implement the extended Javascript runtime, that you would not want running in ring 0. To those are added all the kernel-mode functions that must be used correctly. (If the app can be provoked to use them wrong, boom.) So, the plausible use is an implicitly trusted app not exposed to untrusted input, that is system-call bound, and that you want to distribute cross-platform without recompiling to targets that have installed this module in a known kernel version. It seems easier just to distribute source for a kernel module; or kernel modules built for the (2? 3 tops) architectures required. [edit: spelling error.]

_wmd 8y ago
I'm not sure why linking third party code is a concern, it all must live inside the sandbox provided by the runtime. This reduces the trust requirements from depending on a (software | hardware) solution where the hardware portion cannot be audited, and by 2018 are no longer to be considered trustworthy by default, to only depending on access and bounds checks implemented by a single body of code visible to everyone. The 'system call interface' available to those buggy libraries need be no more capable than existed previously, that system calls are serviced without switching protection mode need not extend the potency of any possible attacks. A future implementation of this style of design will have much better security and auditability properties than anything that has ever popularly existed in the past. It may have originated with the web, but I welcome wasm and all the market punch it promises to bear on ancient and long-unquestioned corners of our software stack like this. (Naturally I was also a Microsoft Singularity fan)
- deathanatos 8y ago
  How does WebAssembly fix hardware issues? For example, take Rowhammer. I don't see how running your code in a VM fixes Rowhammer; surely there would still be some mapping of data in wasm to RAM, and I don't see why a sufficiently motivated individual couldn't determine and subsequently exploit that mapping. Or what does WASM do about the concerns that major CPU vendors embed a second co-processor running untrusted, unauditable code with ring -1 access alongside the main CPU?¹ ¹which may or may not be active, depending on CPU model and configuration. I've never really fully understood when it is, or isn't, but I think it's somewhat moot. Further, this assumes the runtime (which is not just the WASM runtime: system calls and other functionality will inevitably need access to the actual, underlying hardware in order to do their job) from being buggy, and since the code is now in ring 0, you get all the consequences of that. (Full, unrestricted access to everything. At least previously, you'd need to find some root exploit to get that.) (Also, as another poster hints below, since everything is running inside the same protection layer from the CPU's point of view, what prevents you from just running the same attack, in spirit, as Spectre? Only now, there is no protection — everything is ring 0 — so the CPU is "correct" to speculate a read. Sure, the VM will deny it to the code inside the VM, but that didn't matter in the case of Spectre?)

uluyol 8y ago

Serious question: what's the advantage of something like this over eBPF? As I understand it, you can generate eBPF bytecode from C and Linux already has a JIT compiler for it.

telotortium 8y ago
eBPF is a limited, non-Turing complete language, in particular not having loops. Because of this, it's feasible to allow users to upload eBPF filters into the kernel, because execution is safe and and the time to run the filter can be upper-bounded. Wasm, on the other hand, is a memory-safe interpreter, but unlike eBPR is Turing-complete, so it can run arbitrary programs.
- snaky 8y ago
  > in particular not having loops Well, almost. > The main object of this patch series is to support verification of eBPF programs with bounded loops. Only bounds derived from JLT (unsigned <) with the taken branch in the loop are supported, but it should be clear how others could be added. https://lwn.net/Articles/748032/ https://lwn.net/Articles/748032/
kbumsik 8y ago
Many other modern languages such as Rust and Go are aiming to officially support WASM. I don't know much about eBPF but it looks like it only support C for now.
- steveklabnik 8y ago
  A company just announced some cool eBPF and Rust stuff today: https://blog.redsift.com/labs/ebpf-ingrained-in-rust/ https://blog.redsift.com/labs/ebpf-ingrained-in-rust/
- ncmncm 8y ago
  eBPF is generated from LLVM IR, so any language that compiles to IR works, so long as the code doesn't translate to IR operations not permitted in eBPF.

lachlan-sneff 8y ago

nebulet is an implementation of a similar idea, but on a different scale. https://github.com/nebulet/nebulet https://github.com/nebulet/nebulet

moosingin3space 8y ago
How has the work on Nebulet's IPC layer progressed? In theory, a kernel-mode wasm interpreter could make IPC as fast as calling a function in a shared library through a vtable. Of course, this has to be mediated properly to avoid letting processes mess with each others' memory!
- lachlan-sneff 8y ago
  Slowly. I've been quite busy with school. What little time I have spent on nebulet has been on the fledgling network stack.
  - moosingin3space 8y ago
    I see. I'm excited about nebulet and would be interested in participating in the design process for the IPC layer -- is there a place that discussion is taking place?
    - lachlan-sneff 8y ago
      Yeah, totally! The gitter is where most conversations about this take place: https://gitter.im/nebulet/nebulet https://gitter.im/nebulet/nebulet

saurik 8y ago

I have seen at least three projects to run WebAssembly in the kernel, but not a single strong attempt at a good userland binary format for WebAssembly: I don't want to run WebAssembly in my kernel, I just want an architecture agnostic binary format for Linux executables.

comesee 8y ago
Emscripten seems like a good start, the tooling already exists.
AnIdiotOnTheNet 8y ago
Actually, you kinda already have it via QEMU, which is capable of doing syscall translation. Just compile your code for linux on any of the supported target archs and use QEMU User Mode Emulation to launch it.
nwmcsween 8y ago
I don't even think ELF can be architecture agnostic without doing some hideous hacks (aka 'fat' binaries).
- IshKebab 8y ago
  It can because you'd just add Wasm as a new machine type. That would be intrinsically architecture-independent because... it is.
JoshTriplett 8y ago
> I just want an architecture agnostic binary format for Linux executables. What would you use that for, if you had it?
- IshKebab 8y ago
  So you don't have to make different binaries for different architectures? Pretty obvious I would have thought.
- pjmlp 8y ago

justinclift 8y ago

Related to this, the wasm generated by Go is currently tied to being executed in the browser. There doesn't yet seem to be a implementable standard to define what a non-browser execution environment looks like. The beginnings of a common spec are here though, which some places have started working with: https://github.com/CommonWA/cwa-spec https://github.com/CommonWA/cwa-spec That'll likely need to make it's way into the official specs: * https://github.com/WebAssembly/design https://github.com/WebAssembly/design * https://github.com/WebAssembly/spec https://github.com/WebAssembly/spec At which point implementations will have something to focus on. :) For the Go, this is the (recent) matching issue: https://github.com/golang/go/issues/27766 https://github.com/golang/go/issues/27766 Kind of guessing it'll turn into a tracking issue to get it done.

TimTheTinker 8y ago

Another step towards Metal[0] becoming a reality. [0] A (half) joke from Gary Bernhardt's excellent The Birth and Death of JavaScript (pronounced "yavascript"): https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

ArtWomb 8y ago

>>> results in a significant performance increase for syscall-bound programs like web servers Reminds me of "Why we use the kernel's TCP stack"? And eternal debate over the performance benefits of "kernel bypass" and "zero-copy" technologies such as DPDK versus full userspace TCP implementations like OpenOnload. https://blog.cloudflare.com/why-we-use-the-linux-kernels-tcp-stack/ https://blog.cloudflare.com/why-we-use-the-linux-kernels-tcp... Conclusion is that the untapped fruit in kernel TCP gains comes from tuning performance of the network stack itself: optimizing overhead a packet incurs on its path through the stack. A very active area of development. Netdev 0x13, THE Technical Conference on Linux Networking https://netdevconf.org/0x13/ https://netdevconf.org/0x13/

snaky 8y ago
The recent work on AF_XDP seems like it could became established middleground sweet spot almost as efficient as kernel bypass and userspace networking.

elcritch 8y ago

Fascinating concept! Wouldn’t this pause/block the kernel while the module runs? Can’t find anything in the readme. I always assumed kernel modules had to behave politely in terms of returning and not running indefinitely.

gigatexal 8y ago

I’ll keep all my apps if possible in user space please. Call me paranoid.

deleted 8y ago

[deleted]

_pmf_ 8y ago

Finally, full stack engineers live up to their title.