Goal
Run a in-toto inside lind: a step records the files it touched, signs that record (a "link"), and a verifier checks the links against a signed layout. In SGX, the signing happens inside an enclave.
Specifically, we will use the in-toto Rust crate (0.4.0). It is a library with no CLI, no networking and no async. Crypto is ring only. We wrap it in a small CLI with four commands: keygen, run, gen-layout, verify.
We decided to break up the issue in two stages:
Stage 1: Integrate in-toto in lind-wasm and run it in a docker container
The demo flow passes 6/6 under lind_run on lind-server-3: keygen, write-code link, package link, signed layout, verify reports VERIFIED, tampering with foo.py makes verify FAIL. Link hashes match the native build.
Stage 2: Run it on SGX via enarx + the IMFS grate
Pending design decision
Fix (#1378): scripts/rust/make_lind_libc.sh copies libc 0.2.189 from the cargo registry to build/lind-libc and applies scripts/rust/lind-libc-wasi.patch to src/wasi/mod.rs. The patch replaces stat and dirent with the layouts measured under lind, makes off_t/ino_t/nlink_t/blkcnt_t 32-bit, and uses Linux O_, AT_, DT_* and errno values.
The problem is that the Rust libc crate describes the wrong libc
Rust guests on lind are built for wasm32-wasip1. For that target the libc crate uses its wasi module, which describes wasi-libc. lind links the binary against lind-glibc, which uses 32-bit Linux layouts. So std::fs reads struct fields from the wrong offsets and passes wasi flag values to Linux syscalls.
Observed before the fix (probe program under lind):
- metadata().len() = 34359742464 and is_file() = false. st_size read from the wrong offset.
- read_dir() returns entries with empty names. d_name read from the wrong offset.
- File::create() fails with os error 2. wasi O_CREAT bit passed to a Linux open.
in-toto needs symlink_metadata and walkdir to record artifacts, so this has to be fixed first.
Based on my understanding on grates, they never hit this because they do file I/O through raw 3i calls. I also saw that the imfs grate has a workaround comment for the same bug (rust-grates/imfs-grate/src/main.rs:251).
Goal
Run a in-toto inside lind: a step records the files it touched, signs that record (a "link"), and a verifier checks the links against a signed layout. In SGX, the signing happens inside an enclave.
Specifically, we will use the in-toto Rust crate (0.4.0). It is a library with no CLI, no networking and no async. Crypto is ring only. We wrap it in a small CLI with four commands: keygen, run, gen-layout, verify.
We decided to break up the issue in two stages:
Stage 1: Integrate in-toto in lind-wasm and run it in a docker container
The demo flow passes 6/6 under lind_run on lind-server-3: keygen, write-code link, package link, signed layout, verify reports VERIFIED, tampering with foo.py makes verify FAIL. Link hashes match the native build.
Stage 2: Run it on SGX via enarx + the IMFS grate
Pending design decision
Fix (#1378): scripts/rust/make_lind_libc.sh copies libc 0.2.189 from the cargo registry to build/lind-libc and applies scripts/rust/lind-libc-wasi.patch to src/wasi/mod.rs. The patch replaces stat and dirent with the layouts measured under lind, makes off_t/ino_t/nlink_t/blkcnt_t 32-bit, and uses Linux O_, AT_, DT_* and errno values.
The problem is that the Rust libc crate describes the wrong libc
Rust guests on lind are built for
wasm32-wasip1. For that target the libc crate uses its wasi module, which describes wasi-libc. lind links the binary against lind-glibc, which uses 32-bit Linux layouts. So std::fs reads struct fields from the wrong offsets and passes wasi flag values to Linux syscalls.Observed before the fix (probe program under lind):
in-toto needs symlink_metadata and walkdir to record artifacts, so this has to be fixed first.
Based on my understanding on grates, they never hit this because they do file I/O through raw 3i calls. I also saw that the imfs grate has a workaround comment for the same bug (rust-grates/imfs-grate/src/main.rs:251).