Automatically freeing malloc-ed caps in a cross-compartment invocation when the invocation returns

[vmurali]

Sometimes, it's useful to make a cross-compartment invocation truly stateless, and heap is used only for temporary storage. Is there a way to force such an invocation by restricting it to use a different API that automatically frees the allocation on exit (similar to RAII)? One idea I had is to keep track of the allotted caps in the stack (using a virtual sealing type, or using the user bit), and when the stack is popped or zeroed, the corresponding heap memory is freed. There must be an easier way to do this.

[vmurali]

The reason why it cannot simply be on the stack is for systems which have separate (large) heap and (small) stack.

[davidchisnall]

I normally use std::unique_ptr for this. It is RAII. If you want to make it robust in the presence of errors, use the on_error wrapper and define the unique pointer outside of the code that may trap.

[vmurali]

Example where my scenario could be useful: I have third party code that was written with the platform's exposed API (which returns a std::unique_ptr on malloc. But they (inadvertently or maliciously) remove the call to free the pointer in the assembly.

I guess if assembly code can be manipulated, I can't keep any information on the stack (unless stack manipulation results in an architectural exception, for instance when a dynamically allocated pointer is popped or erased). So there's nothing that can be done non-architecturally, and it's too complicated to implement architecturally?

[davidchisnall]

If you're calling untrusted assembly code, that seems like a compartment boundary is the thing. That said, there are a couple of potential approaches:

• You could use a dedicated malloc cap and call heap_free_all afterwards.
• You can use a unique_ptr outside and pass in the allocation.
• You can limit the size of the malloc cap in that compartment so it can DoS itself, but not anyone else.

Not sure if any of these will work for your use case.

[vmurali]

I think heap_free_all is exactly what I am looking for. Let me read up on heap_free_all and make sure it does what I want. Essentially have a wrapper that calls heap_free_all after the actual code of the compartment returns.

[vmurali]

Just confirming my understanding of

cheriot-rtos/sdk/core/allocator/main.cc

Line 956 in 299de3a

__cheriot_minimum_stack(0x190) ssize_t heap_free_all(SObj heapCapability)

:

I go through the whole of the heap, and try to free my chunks there using my specific heapCapability in

cheriot-rtos/sdk/core/allocator/main.cc

Line 975 in 299de3a

if (heap_free_chunk(

Is this how it works?

Yes, this serves the purpose. (Would be better if this can be speeded up instead of doing a full scan later.)

[davidchisnall]

heap_free_all frees all memory allocated from a particular allocator capability except sealed things (we may change that and make heap_free_all a thing that not every allocator capability has). A malicious compartment could stash things as sealed capabilities, but you can use cheriot-audit to make sure that the untrusted compartment does not own any sealing types or call other things that allocate sealed things.

We probably want some helpers in cheriot-audit for providing an allow list of things that a compartment can call.