Giters

CHERIoT-Platform / cheriot-rtos

The RTOS components for the CHERIoT research platform

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Constraints on sealed sizes can be reduced

davidchisnall opened this issue · comments

commented

In the RISC-V standardisation call, @jrtc27 pointed out that we can avoid complexity for the sealing arbitrarily large objects by placing the padding before the header such that the layout is:

  • Padding
  • Otype header
  • Unsealed object
  • Padding (within the unsealed object)

The bounds of the sealed object would then be the full allocation. The address would be the start of the object header. The allocate would ensure that the range from the header to the end is representable. The unseal would do a csetbounds with the size computed from address to top. This should keep the token_unseal simple and cost only a small amount of complexity in token_seal.

commented

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.

commented

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.