Paul Osborne (Feb 28 2025 at 22:30): Paul Osborne (Feb 28 2025 at 22:30):In working on a patch for https://github.com/bytecodealliance/wasmtime/issues/10245 I was attempting to use the min-platform example in tree to do some testing around some of the no_std and #[cfg(not(has_virtual_memory))] paths.
I wanted to confirm whether there was a way to directly get the example to run. Targeting x86_64-unknown-none triple on an x64 host runs but fails out on "cannot load native code - requires virtual memory"
Just want to check that I'm not missing something obvious; I started to try some tweaks to the example to attempt to target pulley64 which should avoid the virtual memory requirement for the embedding.
Alex Crichton (Feb 28 2025 at 22:47):The test on CI is configured here where the general idea is that the host is x64 linux but the guest is "x64 none" so we're sort of lying that it's all embedded
Alex Crichton (Feb 28 2025 at 22:47):in theory though ./build.sh x86_64-unknown-none on an x64 host should work
Paul Osborne (Feb 28 2025 at 23:19):Ok, I have it working now. I had seen the ci test but hadn't looked at the output in detail. Running the build with WASMTIME_SIGNALS_BASED_TRAPS=1 makes the difference to include the custom feature.
Ilya (Mar 09 2025 at 09:39):Speaking of pulley and constrained environments, how can I verify pulley bytecode on the constrained device itself? Right now I'm doing:
let module = unsafe { wasmtime::Module::deserialize(&wasm_engine, include_bytes!("../patch.cwasm")) }.unwrap();
What if I don't necessarily trust the code being loaded?
Is there some different API that allows to validate pulley bytecode being loaded?
bjorn3 (Mar 09 2025 at 09:44):Pulley bytecode is inherently trusted. It can read and write arbitrary memory on the host. Verifying that it doesn't do anything bad would require something like proof carrying code, which is an open research area.
Ilya (Mar 09 2025 at 09:50):Is there any other way to run untrusted code on a constrained device with wasmtime? The device is no_std. Currently it's Cortex-M33 (with MPU) core of rp2350
Alex Crichton (Mar 09 2025 at 17:54):bjorn3 is correct, there's no way to verify the input to Module::deserialize. It's up to the embedder to ensure those are trusted bytes.
Alex Crichton (Mar 09 2025 at 17:54):There is no way to receive an untrusted *.cwasm and run it safely
Ilya (Mar 10 2025 at 08:16):Thanks guys!
Last updated: Apr 07 2025 at 18:04 UTC