Large globals sections are incorrectly set up
davidchisnall opened this issue · comments
CHERIoT-Platform/llvm-project#26 reports that very large objects are not working.
This doesn't appear to be a compiler bug. Extending the test case from that example, we get a capability with the correct bounds, but cgp for the compartment appears to be being created with a zero length and so deriving a capability from that gives an untagged capability. This is presumably therefore a loader bug.
The first issue here is that, currently, the maximum size of a compartment's globals is 64 KiB. Since most devices we're expecting will have much less than 1 MiB of RAM, this isn't really a limitation for any hardware that we expect in the short term. Changing this would increase the size of compartment headers. Most compartments have significantly less than 4 KiB of globals and a lot have 4-20 B, so I wouldn't want to require very strong alignment (storing the size as a shifted value is a simple change).
The test case is an interesting combination of things:
- The globals section must be aligned to be representable.
- It is just under 64 KiB, but rounding it up for representability makes it 64 KiB.
- 64 KiB overflows the size field in the header and so the size is truncated to 0.
- The loader happily creates a 0-byte CGP.
- Ooops.
We should be able to support it, but my initial attempt missed something and does not work. I have not yet discovered why not.
#236 enables 256 KiB of globals per compartment. This is a fairly non-invasive change (I missed the software revoker needing a special case on Friday. Relaxing over the weekend was the right call instead of trying to fix it then).
We could potentially support larger things with a different header format, if necessary, but I don't think we're going to see chips with enough SRAM for this to be a problem in the near future.