Lachlan Gunn (Nov 05 2025 at 16:13): Lachlan Gunn (Nov 05 2025 at 16:13):Hi. We've been doing some work relating to remote attestation of Wasm components (I'll spare you the details for those who aren't into that kind of thing), and have had to make some patches to Wasmtime that we're not sure whether we should (a) throw away and replace with some supported interface that we weren't aware of, (b) generalise and try to upstream, or (c) just maintain in our own fork because they're not of interest to anyone else.
A quick summary of what we've added:
1. During the process of compiling/instantiating a component, we capture a graph of all of the connections between its core modules so that we can get an accurate representation of what code is actually running after things have been linked together (including eventually across machines with wrpc). This is probably a bit too niche for mainline inclusion, but would the interfaces that we're using to extract this kind of data be useful for someone? I was thinking it might be useful somehow e.g. to allow platforms to implement functionality to identify known-vulnerable components or configurations of components without needing to wastefully reparse everything themselves, but maybe it exposes too many internals.
2. The other addition was some new func_wrap variations in the linker to allow host functions to request also information on which component/core module was the source of a call. This is needed in attestation e.g. in order to allow us to signal which part of a large application is terminating a TLS session. But it also kind of violates the usual component model behaviour approach where it doesn't matter who has called an interface.
Would either of these things be more generally useful to others, or are we better off keeping all of this in a completely separate fork for people who want to do our weird kind of confidential computing stuff?
Lann Martin (Nov 05 2025 at 16:33):During the process of compiling/instantiating a component, we capture a graph of all of the connections between its core modules
Is there something about this that is specific to Wasmtime or is this information just currently most conveniently accessible there? (or a 3rd option: neither and I'm just confused :slight_smile: )
Lachlan Gunn (Nov 05 2025 at 16:48):Lann Martin said:
Is there something about this that is specific to Wasmtime or is this information just currently most conveniently accessible there? (or a 3rd option: neither and I'm just confused :slight_smile: )
A bit of both. We can do it outside by analysing the component and then modelling how everything that gets linked together, but this also means that we need to have a good model of what the embedder does, since we want to eventually enable other stuff involving dynamically linking in drivers and access control shims and such. But if it's done directly in Wasmtime then we can get an accurate picture of what's actually running straight from the horse's mouth, without having to replicate the logic of Wasmtime and the embedder and hope that there aren't any subtle differences between the two implementations.
Antoine Lavandier (Nov 05 2025 at 16:54):Lachlan Gunn said:
2. The other addition was some new func_wrap variations in the linker to allow host functions to request also information on which component/core module was the source of a call. This is needed in attestation e.g. in order to allow us to signal which part of a large application is terminating a TLS session. But it also kind of violates the usual component model behaviour approach where it doesn't matter who has called an interface.
Does this allow the Store (maybe another structure) to define some kind of access policies for the host-defined functions ?
Lachlan Gunn (Nov 05 2025 at 16:54):But then for the second part, we want to find the caller of a host function in the graph, so I'm not sure how well it can really be separated in practice.
Lachlan Gunn (Nov 05 2025 at 16:59):Antoine Lavandier said:
Lachlan Gunn said:
2. The other addition was some new func_wrap variations in the linker to allow host functions to request also information on which component/core module was the source of a call. This is needed in attestation e.g. in order to allow us to signal which part of a large application is terminating a TLS session. But it also kind of violates the usual component model behaviour approach where it doesn't matter who has called an interface.
Does this allow the
Store(maybe another structure) to define some kind of access policies for the host-defined functions ?
This was one of the other applications that I had in mind, e.g. If you wanted to host microservices from two different tenants in the one Store but then give them access to different filesystems. Probably this could be achieved in tidier ways like shimming their preloads with another component, but there might be other things that are better implemented in the runtime.
Alex Crichton (Nov 05 2025 at 18:30):Do you have an example of what (1) here might look like in Wasmtime? I'm having a hard time imagining it myself.
For (2) that seems like a reasonable thing to add to Wasmtime myself, but also somewhat dependent on (1) because otherwise it's not clear to me how an internal part of a component would be identified
Lachlan Gunn (Nov 05 2025 at 20:12):Alex Crichton said:
Do you have an example of what (1) here might look like in Wasmtime? I'm having a hard time imagining it myself.
The actual graph itself looks like this:
image.png, or do you mean the code changes?
For (2) that seems like a reasonable thing to add to Wasmtime myself, but also somewhat dependent on (1) because otherwise it's not clear to me how an internal part of a component would be identified
At the moment we're using the OptionsIndex from call_host, which isn't a long-term solution, but we only worked this out yesterday so will hopefully find something less hacky that makes sense independently of the graph.
Alex Crichton (Nov 05 2025 at 20:25):Yeah I'm curious code-changes-wise e.g. how an identifier is used on the host to correlate to internal things within a component. Using OptionsIndex seems like a good starting point though.
Would it make sense to perhaps discuss over a minimal-ish PR or a PR which might end up getting minimized?
Lachlan Gunn (Nov 05 2025 at 20:28):Alex Crichton said:
Yeah I'm curious code-changes-wise e.g. how an identifier is used on the host to correlate to internal things within a component. Using
OptionsIndexseems like a good starting point though.Would it make sense to perhaps discuss over a minimal-ish PR or a PR which might end up getting minimized?
Sounds like a plan. We'll get it tidied up a little more and start the ball rolling.
Lachlan Gunn (Nov 21 2025 at 10:05):Alex Crichton said:
Yeah I'm curious code-changes-wise e.g. how an identifier is used on the host to correlate to internal things within a component. Using
OptionsIndexseems like a good starting point though.Would it make sense to perhaps discuss over a minimal-ish PR or a PR which might end up getting minimized?
Sorry to keep you waiting while we made things a bit more presentable, but the PR is up now here.
Last updated: Dec 06 2025 at 06:05 UTC