determining operational cageid for syscalls.

[stupendoussuperpowers]

Moving the discussion from the grates repo to here.

Currently, when a syscall execution hits rawposix, the way it determines the original calling cage changes based on individual syscalls, and the process of extracting this can lead to breakages in the semantic understanding of what the make_threei_call arguments represent. In most cases, this operational cageid is extracted from an arbitrary (argX, argXcageid) tuple.

Walking through this setup:

• We run chroot-grate.wasm --chroot-dir /tmp program.wasm
• When program.wasm issues open("/path", ...), it is intercepted by the chroot-grate which will change the path to /tmp/path.
• This new path buffer (/tmp/path) now exists in the grate's memory, so we will now call make_threei_call(..., new_path, grateid,...).
• The current way open_syscall in rawposix handles things, the operational_cageid is determined by the path_arg_cageid, so in this scenario it would call open on behalf of the chroot-grate, and not program.wasm, and an FD will be opened for the grate.
  

  lind-wasm/src/rawposix/src/fs_calls.rs

  Lines 100 to 107 in 678448c

  	// Due to 3i syscall interposition, `cageid` refers to the
  	// current execution context (possibly a forwarding grate), not
  	// necessarily the original caller.
  	//
  	// For syscalls like `open`, the operation must be performed on the
  	// the originating cage. Therefore, we derive the semantic operation
  	// cage from the argument metadata (`path_cageid`).
  	let operation_cageid = path_cageid;

In the implementation that exists right now, the only safe way to modify open's path buffer is to overwrite the existing argument, and this will only be safe in cases where the new_path length is equal to or less than the original path.

We have the following possible fixes for this:

1. Use unused args to represent the operational cageid: For e.g. (arg6, arg6cage) when unused. Cons: This is a little hacky, and might lead to problems for syscalls that utilize all 6 arguments. It also breaks the contract of where (argX, argXcage) are only supposed to be used for address translations without any hidden meaning.

2. Change the semantics of how (selfcageid, targetcageid) work. Cons: This is a really complicated change.

3. For make_threei_call replace the unused syscall_name parameter to represent the operational cageid instead, and change rawposix syscall signatures to add an added parameter called operational_cageid. We would also need to change the signature of pass_fptr_to_wt so that grates know which cage it received this call from.

[Yaxuan-w]

For make_threei_call replace the unused syscall_name parameter to represent the operational cageid instead, and change rawposix syscall signatures to add an added parameter called operational_cageid. We would also need to change the signature of pass_fptr_to_wt so that grates know which cage it received this call from

Syscall_name is used in glibc, but we can have an additional arg in function signature to represent source cageid.

[JustinCappos]

I'm a bit confused by the framing. Isn't there a target cage (like for fork, exec, etc.)? This is where the fd should be created, right? I don't think the path string location should ever be considered in this equation.

…

On Sat, Mar 7, 2026 at 2:50 PM Alice Wen ***@***.***> wrote: *Yaxuan-w* left a comment (Lind-Project/lind-wasm#896) <#896 (comment)> For make_threei_call replace the unused syscall_name parameter to represent the operational cageid instead, and change rawposix syscall signatures to add an added parameter called operational_cageid. We would also need to change the signature of pass_fptr_to_wt so that grates know which cage it received this call from Syscall_name is used in glibc, but we can have an additional arg in function signature to represent source cageid. — Reply to this email directly, view it on GitHub <#896 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD5SONW7FM3PT3LHP334PR4QLAVCNFSM6AAAAACWKRJXTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMJXGIYTMMJWGE> . You are receiving this because you were assigned.Message ID: ***@***.***>

[stupendoussuperpowers]

@Yaxuan-w can maybe comment more on feasibility/effort required for this change, and add more details here.

Isn't there a target cage (like for fork, exec, etc.)? This is where the fd should be created, right?

Right now, target_cageid doesn't mean much outside of the (selfcage, targetcage) tuple, and this tuple is used only to determine where next to route this call to, and not which cage should run these calls. For instance, an interposing grate has to call make_threei_call(selfcage=grateid, targetcage=RAWPOSIX_CAGEID) to indicate that the next step for this call should be to rawposix, it contains no information about which cage the call should be called on behalf of.

[Yaxuan-w]

Fix of removing operational cageid in #900

[JustinCappos]

Okay, my thought was that the operational_cageid is the thing to apply it to and the other cage is the one making the call. Calls would always go from the executing grate’s table on down. So a grate doesn’t have a built-in way to actually make the system call its child would and have it (for example) pass through the grates under the child. Or at least, if this is desired, it would need to watch to see what handler is registered for the child, save that reference, and call it themself with the appropriate args

…

— Reply to this email directly, view it on GitHub <#896 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRODYF3MKXZO63OY5D3H34PTYIHAVCNFSM6AAAAACWKRJXTGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMJYGI4TCOBTGQ> . You are receiving this because you were assigned.Message ID: ***@***.***>

[stupendoussuperpowers]

Moving my comment from #900 here -

The original reason for implementing this change was to allow for e.g. (path_cage, path_cageid) to be independent of the calling cage. This needs more work to be generally available.

• All address translations happen within glibc, and rawposix/threei modules expect to receive every address encoded in the host address space, and not the uaddr space.
• When a grate calls something along the lines of:

  make_threei_call(
  ...,
  my_new_path, mycageid,
  ...)

my_new_path is a cage-local address.

• For copy_data_between_cages, we translate possible uaddrs to host addrs through TRANSLATE_UADDR_TO_HOST macro. This is only possible because we know for a fact that both src and dest arguments are supposed to be addresses.
• This approach will therefore not work for make_threei_call since this would also translate arguments that are non pointers. (e.g. MAP_FIXED will get converted to an random address instead of being retained as an integer).

For my tests right now, I exposed the lind_get_memory_base function through lind_syscall.h, and manually added this to the my_new_path to get a valid host-coded address. This is a cumbersome change and I am not sure if we want cages to be aware of their base memory addresses.

It's worth considering whether we want argXcageid to always be populated or if we could set this to 0 for non addresses since their meaning is not impacted by their associated cageid. This would allow us to skip translating them in the glibc macro.

[rennergade]

It's worth considering whether we want argXcageid to always be populated or if we could set this to 0 for non addresses since their meaning is not impacted by their associated cageid. This would allow us to skip translating them in the glibc macro.

At first glance this seems like a reasonable solution to me.

[JustinCappos]

I think you can set it to be zero when the cageid is the current cage or similar. If it's a different cage, then you need to do the work.

I agree that for most pass-by-value arguments, this is nonsensical. It isn't necessarily nonsensical for things like fds, that have state which is outside of the current cage scope. However, that translation is handled without changing addresses.

I wonder if really the 'difference' here is that addresses need to be translated, so the args must be transformed. In other cases, I think it's fairly straightforward and just involves passing the arg and a grate, etc. checking the relevant cage id for the arg.