Constraints on sealed sizes can be reduced about cheriot-rtos

[vmurali]

I am not sure I understand the issue, or how this proposal solves the issue. Moreover, shouldn't the API allow access without allowing access to the header (i.e. unseal should be from end of otype header to top)?

Finally, why is the header currently not stored in top? Since top is representable, and should not be accessed, it looks like a perfect place to put the header. Moreover, unless E is 0, we have at least 16 bytes at the top.

[davidchisnall]

I am not sure I understand the issue, or how this proposal solves the issue

This issue is that we must be able to precisely represent two capabilities:

• The unsealed capability to the object
• The sealed capability to the object plus the header.

Placing the header at the top or bottom does not alter this.

Moreover, shouldn't the API allow access without allowing access to the header (i.e. unseal should be from end of otype header to top)?

Yes, exactly. The token_unseal call needs to be able (in a way that is simple to ensure is correct) be able to take a sealed capability to object+header and create a precisely bounded capability to just the object.