Lind as a shared library

[vidyalakshmir]

Sandbox a native library: run a wasm-compiled library as a drop-in .so

Summary

Adds the plumbing to compile a library to WebAssembly, run it as a guest inside the lind/wasmtime sandbox, and expose it as an ordinary native .so. An unmodified native app links the .so and calls its functions normally, unaware the work happens inside a wasm sandbox.

This delivers the first end-to-end slice: a libadd_sub.so whose add/subtract run inside a wasm cage. Functions are scalar-only, so this proves the runtime + packaging plumbing in isolation, before any data marshalling.

Components

lind-boot embedding API
Refactors startup so the same path can either run an entry point (the binary) or hand back a live instance (a library):

PoC + build harness (lind-sharedlib-poc/)
One self-contained folder per iteration under examples/. 01-scalars has the guest library, an unmodified native demo.c, and the cdylib stub crate. tools/gen_stubs.sh generates the extern "C" stubs from a functions.txt manifest; the guest module is staged into lindfs/ via lind_compile --output-dir.

Build and run

Prereq: make build once at repo root.

cd lind-sharedlib-poc/examples/01-scalars
make            # build only (build & run can be on different machines)
make run        # run the wasm-sandboxed libadd_sub.so
make run-native # baseline: real native lib, no sandbox

Both print add(2, 3) = 5 / subtract(10, 4) = 6.

Scope

Currently works for libraries with functions with scalar arguments.

Next steps : Support for pointer, buffer, string, struct, callback marshaling, per-thread concurrency, stub codegen from headers.

[Yaxuan-w]

execute_wasmtime() still interprets the first returned Val::I32 as the process exit code. In normal _start mode that makes sense, but in --call add ... 2 3 mode the return value is the function result, i.e. 5. That means a successful lind_run --call add ... exits with status 5, which is abnormal for the lind-wasm runtime exit. Moreover, the new make check target will also fail even though the call succeeded.

In --call mode the return values should be printed/returned to the caller, but the process exit status should be 0 unless invocation failed.

[Yaxuan-w]

We don't chroot here.. Should we also have fs isolation on lib mode?

[Yaxuan-w]

We always use CAGE_START_ID while RawPOSIX/3i/cage state is process-global. This works for exactly one generated .so, but if a host loads two sandboxed libraries, or two different wrappers both call init_sandboxed_lib, they will both try to install state for the same cage id.