← Back to context

Comment by westurner

3 days ago

How should a microkernel run (WASI) WASM runtimes?

Docker can run WASM runtimes, but I don't think podman or nerdctl can yet.

From https://news.ycombinator.com/item?id=38779803 :

  docker run \
    --runtime=io.containerd.wasmedge.v1 \
    --platform=wasi/wasm \
    secondstate/rust-example-hello

From > ostree native containers are bootable host images that can also be built and signed with a SLSA provenance attestation; https://jangafx.com/insights/linux-binary-compatibility :

> To handle this correctly, each libc version would need a way to enumerate files across all other libc instances, including dynamically loaded ones, ensuring that every file is visited exactly once without forming cycles. This enumeration must also be thread-safe. Additionally, while enumeration is in progress, another libc could be dynamically loaded (e.g., via dlopen) on a separate thread, or a new file could be opened (e.g., a global constructor in a dynamically loaded library calling fopen).

FWIU, ROP Return-Oriented Programming and Gadgets approaches have implementations of things like dynamic header discovery of static and dynamic libraries at runtime; to compile more at runtime (which isn't safe, though: nothing reverifies what's mutated after loading the PE into process space, after NX tagging or not, before and after secure enclaves and LD_PRELOAD (which some go binaries don't respect, for example).

Can a microkernel do eBPF?

What about a RISC machine for WASM and WASI?

"Customasm – An assembler for custom, user-defined instruction sets" (2024) https://news.ycombinator.com/item?id=42717357

Maybe that would shrink some of these flatpaks which ship their own Electron runtimes instead of like the Gnome and KDE shared runtimes.

Python's manylinux project specifies a number of libc versions that manylinux packages portably target.

Manylinux requires a tool called auditwheel for Linux, delicate for MacOS, and delvewheel for windows;

Auditwheel > Overview: https://news.ycombinator.com/item?id=42347468 :

> A manylinux_x_y wheel requires glibc>=x.y. A musllinux_x_y wheel requires musl libc>=x.y; per PEP 600

3 comments

westurner

Reply
dpassens  2 days ago

> How should a microkernel run (WASI) WASM runtimes?

Same as any other kernel—the runtime is just a userspace program.

> Can a microkernel do eBPF?

If it implements it, why not?

  • westurner  2 days ago

    Should a microkernel implement eBPF and WASM, or, for the same reasons that justify a microkernel should eBPF and most other things be confined or relegated or segregated in userspace; in terms of microkernel goals like separation of concerns and least privilege and then performance?

    Linux containers have process isolation features that userspace sandboxes like bubblewrap and runtimes don't.

    Flatpaks bypass selinux and apparmor policies and run unconfined (on DAC but not MAC systems) because the path to the executable in the flatpaks differs from the system policy for */s?bin/* and so wouldn't be relabeled with the necessary extended filesystem attributes even on `restorecon /` (which runs on reboot if /.autorelabel exists).

    Thus, e.g. Firefox from a signed package in a container on the host, and Firefox from a package on the host are more process-isolated than Firefox in a Flatpak or from a curl'ed statically-linked binary because one couldn't figure out the build system.

    Container-selinux, Kata containers, and GVisor further secure containers without requiring the RAM necessary for full VM virtualization with Xen or Qemu; and that is possible because of container interface standards.

    Linux machines run ELF binaries, which could include WASM instructions

    /? ELF binary WASM : https://www.google.com/search?q=elf+binary+wasm :

    mewz-project/wasker https://github.com/mewz-project/wasker :

    > What's new with Wasker is, Wasker generates an OS-independent ELF file where WASI calls from Wasm applications remain unresolved.*

    > This unresolved feature allows Wasker's output ELF file to be linked with WASI implementations provided by various operating systems, enabling each OS to execute Wasm applications.

    > Wasker empowers your favorite OS to serve as a Wasm runtime!

    Why shouldn't we container2wasm everything? Because (rootless) Linux containers better isolate the workload than any current WASM runtime in userspace.