Questions regarding call, exec, and a potentially missing variant

[bitwalker]

I think first and foremost, I think it would be helpful to have some documentation on when one would choose call vs exec, as aside from the execution context change, the only other difference appears to be that exec inlines the callee at the call site, whereas call does not - but it isn't clear to me that this is a meaningful difference. On the surface, being able to call a function without inlining it appears like it would be useful since it would allow cycles in the call graph (i.e. A calls B which calls C which calls B, which then returns all the way back up to A); but that isn't supported today, unfortunately.

On a related note, something that seems to be missing is a call operation which lets the callee inherit the callers execution context (or perhaps a portion of it, maybe based on something akin to capabilities). Without one, it looks to me like it is impossible to pass large values into a new context (e.g. a string or large structure allocated in global memory). One other option might be to make execution contexts a first class value in MASM, such that you can create/destroy a context, allocate in it, and either pass it around or be able to provide it to call in place of a "fresh" context. At a high level though, the basic issue is that there doesn't appear to be a way to call an external procedure with large values, unless I'm missing something.

[bobbinth]

I think first and foremost, I think it would be helpful to have some documentation on when one would choose call vs exec, as aside from the execution context change, the only other difference appears to be that exec inlines the callee at the call site, whereas call does not - but it isn't clear to me that this is a meaningful difference.

Agreed - we could improve the documentation. Let's create an issue for this.

But to briefly describe it here: by far, the biggest difference is that call executes a procedure in a different memory context and the caller's context is not accessible from the callee's context. Thus, we should use call when calling "untrusted" code (i.e., code which needs to run in an isolated environment because we don't fully know what it could do). In all other situations, exec should be preferred because it should be more efficient.

Another thing to mention: call also kind of inlines the procedure - it just just does extra things as compared to exec (i.e., creates new memory context, truncates the stack etc.). But we can't use call to recursively call the same procedure (or any sequence of procedures which would form a cycle).

On the surface, being able to call a function without inlining it appears like it would be useful since it would allow cycles in the call graph (i.e. A calls B which calls C which calls B, which then returns all the way back up to A); but that isn't supported today, unfortunately.

I think the issue is reversed here: with the current structure, we must inline all the code and that's why we can't support cycles. If we find a way how not to inline some code (the PCALL operation discussed in #728 might be a way to do that), then we should be able to support cycles.

On a related note, something that seems to be missing is a call operation which lets the callee inherit the callers execution context (or perhaps a portion of it, maybe based on something akin to capabilities). Without one, it looks to me like it is impossible to pass large values into a new context (e.g. a string or large structure allocated in global memory).

As mentioned above, call should be used only when we really need context isolation to run untrusted code. Otherwise, exec can be used and then we can reference any part of memory directly without the need to copy it.

We could introduce instructions in the future which would allow copying segments of memory within and between contexts, but for each memory location copied, we's still need to insert a read and a write entry into the memory trace - so, it doesn't save a lot.

Right now, the approach for passing lots of data between contexts is to use mem_stream instruction in the caller's contxt to compute a hash of some memory region, and then non-deterministically "unhash" this value in the callee's context using adv_pipe instruction. This is even less efficient than dedicated instructions for copying memory segments, but it does work.