Consider adding instructions to read memory of the parent context

[bobbinth]

One of the consequences of #948, is that we would get access to the parent context ID via prnt_ctx column. This means, we would be able to execute operations which read values from (and even write values to) parent memory.

While writing values into parent context may lead to potential security issues, reading values should be OK in most cases, and it could simplify passing large amounts of data from the caller to the callee.

The instructions could be something like pmem_load and pmem_loadw (to mimic mem_load and mem_loadw).

[hackaugusto]

Question: Could this be extended to all contexts? For example, allowing a note context to pass a pointer and length to the kernel context, for things like assets on a create_note call.

Note: This may be a security vulnerability if a secret is stored in the root context and the note can read it. Maybe it should be limited for a high priority context allowed to read a lower priority context memory? Or maybe a specific memory region should be private and some other area readable (although this makes it harder to write correct code)

[bobbinth]

Yes - we could extend it to all contexts - the tricky thing is to get the correct context ID. So, for example, if we want the code executing in root context to read memory from note context, we'd need to pass the following to create_note: note's context ID, pointer, length.

We currently don't have an instruction to get current context ID - though, I don't think there is a reason why we can't add it.

[bitwalker]

Something to note here: this could be done safely using some of my suggestions on the topic of a "Miden component model". Specifically, the ability to switch between arbitrary contexts, and associating "resources" with contexts (see the concept of resources in the Wasm Component Model, documented here). Resources provide a capability-object model that maintains the security of the underlying architecture (Wasm, or in our case, Miden), while also enabling a lot of powerful use cases that would otherwise not be possible.

To provide a bit more detail - resources allow a context to share data with other contexts in the form of a handle, with corresponding ownership semantics (own vs borrow). A resource handle can be used to execute code that operates on its data and only that data. Each resource can have zero or more methods associated with it, and when a method is invoked on a resource, the code associated with it is executed in the context which created the resource, which has full control over it. In effect, the actual memory of the resource isn't shared, but you can do virtually everything of interest as if it was. Typically, resources are associated with capabilities (as part of the resource itself), which determine what the owner of the resource handle can do with the resource - this is the essence of the capability-object model mechanism.

All that to say, I think if we want to start exploring solutions to problems like these, I would strongly recommend that we do so by tackling the fundamental elements we need to implement parts of the component model framework in Miden VM. We'll end up with a much more cohesive set of primitives, which will in turn let us solve not only this problem, but a host of related ones.