Large globals sections are incorrectly set up

[davidchisnall]

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.

[davidchisnall]

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.

[sleffler]

The test case was distilled from real code that uses a larger buffer to capture real time audio data. Not supporting this use case will limit applications (I'd argue it's not uncommon in systems that process sensor data). Having an opt-in mechanism to do this (at a cost) would be great; I haven't looked at the ldscript's in depth to understand what might be do-able (or perhaps this is dependent on the bounds encoding which I'm not familiar with other than it's a point of contention). At minimum getting a build-time error when exceeding limits would be good (a quick glance at the ldscript cmd language doesn't turn up any help; probably need to pre-process data).

…

On Fri, May 24, 2024 at 7:50 AM David Chisnall ***@***.***> wrote: 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. — Reply to this email directly, view it on GitHub <#230 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABRM7IKOGAME7RTWKGMBM7TZD5HSFAVCNFSM6AAAAABIHUQVHWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRZG4ZDMNJWGY> . You are receiving this because you are subscribed to this thread.Message ID: <microsoft/cheriot-rtos/issues/230/2129726566 <(212)%20972-6566>@ github.com>

[davidchisnall]

We should be able to support it, but my initial attempt missed something and does not work. I have not yet discovered why not.

[davidchisnall]

#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.