From 9ef5c9ac0f946d7ba587df841f193dbedb4b6051 Mon Sep 17 00:00:00 2001 From: Christof Petig Date: Tue, 7 Jan 2025 19:05:02 +0100 Subject: [PATCH] Today's meeting minutes (draft before watching the video) --- SIG-Embedded/2025/01-07-Meeting-notes.md | 75 +++++++++++++++++++++++- 1 file changed, 73 insertions(+), 2 deletions(-) diff --git a/SIG-Embedded/2025/01-07-Meeting-notes.md b/SIG-Embedded/2025/01-07-Meeting-notes.md index e806bab..6815bda 100644 --- a/SIG-Embedded/2025/01-07-Meeting-notes.md +++ b/SIG-Embedded/2025/01-07-Meeting-notes.md @@ -33,8 +33,79 @@ ## Notes -* TODO +* Introduction to memory control: + + The [memory control proposal by Google](https://github.com/WebAssembly/memory-control/) + defines e.g. read only memory. + (Note by author virtual mode is likely the one eSIG is looking for because the other sub-proposals are too limited.) + + Luke proposed to use shared memory for zero-copy streams, [probably this link](https://github.com/WebAssembly/component-model/issues/369#issuecomment-2484459838) + + The core group is currently discussing memory control, Google is preferring + zero hardware requirements. + +* [Hardware requirement clarification](https://github.com/bytecodealliance/sig-embedded/issues/7): + + Chris found no hardware with 500kB of RAM which doesn't provide at least an MPU. + Requiring an MMU might be possible as a project requirement. The existence of an + RTOS can be assumed. + + The proposed RISC-V chip comes with an MPU like device called PMP, see [this link](https://github.com/bytecodealliance/sig-embedded/issues/7#issuecomment-2574759255) + + On Cortex-M an MPU is optional, but M4/M7 typically provide it, M0 might need special + workarounds (CPU cost). + + The [Cyber Resilience Act](https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act) will likely require sandboxing. + + [Option 5](https://github.com/WebAssembly/memory-control/issues/19) will likely be able + to support chips without MMU by a copy and without an MPU by [masking](https://github.com/gwsystems/aWsm) + + Discontinous memory can avoid copying and masking with an MPU might result + in non-conformant sandboxing of the binary (e.g. accesses into the hole might not trap). + +* Three phases for shared memory implementation: + + 1. Mapping shared memory into an address space of the module + 2. (?) Implementing subpartitioning of the memory + 3. Handling mutual access to parts of the memory + +* Basically there are two different approaches to shared memory design + + - bottom-up approach: Provide primitives for low level shared memory and work + from there. Most likely compatible with existing software design. Equivalent + to Option 1 to 4. + + - top-down approach: Provide semantic access to shared memory based on high-level + API design. Best for sandboxing and portability. Equivalent to Option 5. + + Option 6 might align well with CHERI hardware capabilities. + + Ayako confirmed that they are currently [going for](https://github.com/bytecodealliance/wasm-micro-runtime/issues/3546) Option 4, because this doesn't + require an MPU. With an MPU native code would be the more performant choice providing + similar sandboxing. + + It looks like there is currently no size-fits-all approach within the eSIG. + +* Proposal to create a Matrix of options and hardware capabilities. + + - To be clarified: Which axises should span the matrix, Chris will make a proposal + and wait for feed-back. + +* Interaction with other parts of the community + + - Marcin will discuss multithreading solutions with Andrew Brown later this week. + + - The activation of reftypes by default by the WASI SDK created a portability + roadblock, the ability to turn it off requires a nightly Rust compiler. + + - A bridge between WASIp2 for a WASIp1 environment added to the agenda + of the next eSIG meeting. + + - [WASI 0.3 is progressing nicely](https://github.com/orgs/bytecodealliance/projects/16), wasm-tools contains the changes, + [wit-bindgen](https://github.com/bytecodealliance/wit-bindgen/pull/1082) is in review phase, [wasmtime](https://github.com/bytecodealliance/wasmtime/pull/9582) is worked on. + + There is already an [early prototype of Streams with native compilation](https://github.com/cpetig/wit-bindgen/tree/main/crates/cpp/tests/symmetric_stream). ## Action Items -* [ ] TODO +* [ ] Create Matrix of shared memory requirements