4 ms·

It's only a matter of time until we have metered WebAssembly in the kernel :)

• moring 6y ago
  Actually, why not? The main reason that "in the kernel" is concerning is because untrusted code needs some kind of sandboxing, either by static analysis or by run-time checks. (Most modern systems do a combination of both). After all, the whole "in the kernel" vs. "in userland" distinction only exists because we get hardware-accelerated sandboxing from the CPU and OS combined.
  • 7373737373 6y ago
    Yeah, my comment is actually unironic :) There are a few ways to limit the execution time of wasm programs: - inject code after a set of instructions with a certain duration and in each loop that calls an external function which meters and destroys/suspends execution when a limit is reached (e.g. https://github.com/ewasm/wasm-metering https://github.com/ewasm/wasm-metering) - use a VM which counts instructions (e.g. https://github.com/perlin-network/life https://github.com/perlin-network/life) - use hardware interrupts More random thoughts: https://esolangs.org/wiki/RarVM https://esolangs.org/wiki/RarVM
• m4r35n357 6y ago
  We all know the Linux kernel needs a more "engaging" UX . . .
• htfy96 6y ago
  I guess running an alternative language in kernel is not very challenging. (I tried it two years ago and managed to run i8042 keyboard driver in WebAssembly on Qemu) The hard part is interoperability. Even in languages with automatic C header -> native prototypes conversion capabilities, many kernel features are still not properly handled, especially the macros. Status quo requires the user to manually extract wrappers which could be super tedious.