4 ms·

A BPF interpreter can literally be ~100 LoC. A WebAssembly VM on the other hand will likely be ~1million LoC (without checking). One is suitable for embedding

A BPF interpreter can literally be ~100 LoC. A WebAssembly VM on the other hand will likely be ~1million LoC (without checking). One is suitable for embedding into a kernel, the other isn't.

sanxiyn 7y ago
Where did you get ~1million number? https://github.com/bytecodealliance/wasm-micro-runtime https://github.com/bytecodealliance/wasm-micro-runtime is less than 100K LoC for example.
- 0-_-0 7y ago
  If a micro runtime is 100K LOC then 1M LOC wasn't unrealistic.
  - sanxiyn 7y ago
    About half is tests and sample codes. Runtime proper (core directory) is <50K. It is also WASI runtime. WebAssembly runtime proper (core/iwasm/runtime directory) is more like 10K.
- kbumsik 7y ago
  This is a micro runtime that acts as a tiny WASM interpreter. 1M LOC sounds fair when complex runtime features such as JIT or AOT are included.
nicoburns 7y ago
> One is suitable for embedding into a kernel, the other isn't. I'd be very surprised if the linux kernel doesn't eventually get web assembly support.
- manyworlds 7y ago
  Doubtful. Webassembly is Turing complete, BPF isn’t. Running untrusted unbounded code in the kernel is not smart. BPF was invented with kernel constraints in mind, webassembly was invented with browser constraints in mind. Completely different use cases
  - nicoburns 7y ago
    > Running untrusted unbounded code in the kernel is not smart. Well currently we run code (e.g. drivers) as trusted full-permission code. Surely, web-assembly would be better than this from a security perspective.
    - manyworlds 7y ago
      Generally kernel code is also written to specific constraints. Out-of-tree drivers are usually bad at conforming and hypothetical out-of-tree webassembly drivers would be bad for similar reasons. Memory safety isn’t enough, using kernel interfaces safely requires conformance that webassembly can’t statically guarantee like BPF can Basic examples: code that takes a lock and never releases it, code that loops forever, code that leaks kernel resources.
    - boomlinde 7y ago
      What use case do you envision?
      - mkup 7y ago
        Out-of-tree drivers, support for closed-source drivers in Linux (assuming kernel API for wasm drivers is stable).
        boomlinde 7y ago
        While I see how out-of-tree drivers using a stable API might be a desirable goal, I don't understand what WASM adds to the table. Maybe some degree of cross-arch portability, but that's already afforded by C and the kernel.
mwcampbell 7y ago
> without checking Then how can you possibly know? Do you just assume that because it has "Web" in the name, it must be insanely complicated?
ClumsyPilot 7y ago
Thank you, I appreciate the perspective. Perhaps WebAssembly kernel-space programming would still be viable for major trusted projects, like Kafka, where you literally dedicate the entire machine to that application.
- manyworlds 7y ago
  Unikernel or rump kernel would be better for that purpose

A BPF interpreter can literally be ~100 LoC. A WebAssembly VM on the other hand will likely be ~1million LoC (without checking). One is suitable for embedding into a kernel, the other isn't.

sanxiyn 7y ago

Where did you get ~1million number? https://github.com/bytecodealliance/wasm-micro-runtime https://github.com/bytecodealliance/wasm-micro-runtime is less than 100K LoC for example.

0-_-0 7y ago
If a micro runtime is 100K LOC then 1M LOC wasn't unrealistic.
- sanxiyn 7y ago
  About half is tests and sample codes. Runtime proper (core directory) is <50K. It is also WASI runtime. WebAssembly runtime proper (core/iwasm/runtime directory) is more like 10K.
kbumsik 7y ago
This is a micro runtime that acts as a tiny WASM interpreter. 1M LOC sounds fair when complex runtime features such as JIT or AOT are included.

nicoburns 7y ago

> One is suitable for embedding into a kernel, the other isn't. I'd be very surprised if the linux kernel doesn't eventually get web assembly support.

manyworlds 7y ago
Doubtful. Webassembly is Turing complete, BPF isn’t. Running untrusted unbounded code in the kernel is not smart. BPF was invented with kernel constraints in mind, webassembly was invented with browser constraints in mind. Completely different use cases
- nicoburns 7y ago
  > Running untrusted unbounded code in the kernel is not smart. Well currently we run code (e.g. drivers) as trusted full-permission code. Surely, web-assembly would be better than this from a security perspective.
  - manyworlds 7y ago
    Generally kernel code is also written to specific constraints. Out-of-tree drivers are usually bad at conforming and hypothetical out-of-tree webassembly drivers would be bad for similar reasons. Memory safety isn’t enough, using kernel interfaces safely requires conformance that webassembly can’t statically guarantee like BPF can Basic examples: code that takes a lock and never releases it, code that loops forever, code that leaks kernel resources.
  - boomlinde 7y ago
    What use case do you envision?
    - mkup 7y ago
      Out-of-tree drivers, support for closed-source drivers in Linux (assuming kernel API for wasm drivers is stable).
      - boomlinde 7y ago
        While I see how out-of-tree drivers using a stable API might be a desirable goal, I don't understand what WASM adds to the table. Maybe some degree of cross-arch portability, but that's already afforded by C and the kernel.

mwcampbell 7y ago

> without checking Then how can you possibly know? Do you just assume that because it has "Web" in the name, it must be insanely complicated?

ClumsyPilot 7y ago

Thank you, I appreciate the perspective. Perhaps WebAssembly kernel-space programming would still be viable for major trusted projects, like Kafka, where you literally dedicate the entire machine to that application.

manyworlds 7y ago
Unikernel or rump kernel would be better for that purpose