Clarify (and possibly better enforce) the semantics of de-allocation

[hlef]

We do not clearly define the semantics of the allocator with regards to de-allocation.

For example, is free() supposed to be allowed with an entirely de-permissioned capability? Currently, the allocator will happily free an object if passed a capability to that object and a matching allocator capability, even if the capability pointing to the object has no permissions. Is that what we want? Or should the allocator only accept to free with a fully-privileged capability as returned by heap_alloc?

One scenario that justifies the current behavior is the following: A compartment allocates an object and initializes it. At that stage the object is only used in a read-only manner, so the compartment drops its permissions to read-only to enforce least-privilege. Later, the compartment wants to free the object, but it does not have a fully-privileged capability to that object anymore. So the allocator should accept the read-only capability.

I am not sure we want to change the current behavior but I think it is worth a small discussion.

This question was raised as part of an ongoing verification effort of the memory allocator at the UBC.

We should:

• Make a decision on the problem above;
• And clearly document the semantics of the allocator in a design document.

[davidchisnall]

Good question. We don’t allow free on partial objects, so it would be consistent to do a permission check as well, but I agree that this is an interesting use case.

[nwf]

We don’t allow free on partial objects

Well... the present policy's more nuanced than that, right? A subset pointer is not sufficient to allow an object's owner to discard its distinguished primacy... but it is sufficient to allow any party, object's owner or not, to drop a claim. Moreover, we do discard owner primacy as soon as possible, so if ever the object's owner has passed a full pointer, we will have done so, even if the intent at the time was to merely drop a claim.

See

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

  Lines 778 to 788 in ba5cde4

  	// If this is a precise allocation, see if we can free it as the
  	// original owner. You may drop claims with a capability that is a
  	// subset of the original but you may not free an object with a subset.
  	if (isPrecise && (chunk.owner() == owner.identifier))
  	{
  	if (!reallyFree)
  	{
  	return 0;
  	}
  	size_t chunkSize = chunk.size_get();
  	chunk.ownerID = 0;

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

  Lines 805 to 809 in ba5cde4

  	// If this is an interior (but valid) pointer, see if we can drop a
  	// claim.
  	if (claim_drop(owner, chunk, reallyFree))
  	{
  	if ((chunk.claims == 0) && (chunk.ownerID == 0))

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

  Line 844 in ba5cde4

  bool isPrecise = (start == mem.base()) && (bodySize == mem.length());

[davidchisnall]

The consensus from the chat seemed to be that the desired semantics should prevent you from freeing an object without G, but, as @nwf says, this shouldn't affect claim dropping.

I do slightly wonder if we should error if you claim an object that you own.

[hlef]

@tolbooth Do you want to prepare a PR to enforce this? It should be a fairly accessible issue to look at.

[tolbooth]

I'm going to open a PR to address this issue. I've posted some further questions in the signal chat.

Regarding, @davidchisnall, your second point: the behavior right now is to downgrade our ownership to a claim, as I understand it? I'll open a second issue for this, as I believe there're some unintended effects.