Large globals sections are incorrectly set up #230
Comments
|
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 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>
|
|
We should be able to support it, but my initial attempt missed something and does not work. I have not yet discovered why not. |
We store the size of globals as a shifted value, which extends the maximum size of globals in a compartment from 64 KiB to 256 KiB. This adds two new tests. One is added to the misc test and just checks that we correctly handle globals that are larger than the range of a csetbounds with an immediate offset. The second checks that much larger globals work. This test is disabled because it uses so much RAM that we don't have enough for the allocator tests. At some point, we should refactor the test suite to allow subsets of the test suite to be built. Add test for large objects. Fixes #230
|
#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. |
We store the size of globals as a shifted value, which extends the maximum size of globals in a compartment from 64 KiB to 256 KiB. This adds two new tests. One is added to the misc test and just checks that we correctly handle globals that are larger than the range of a csetbounds with an immediate offset. The second checks that much larger globals work. This test is disabled because it uses so much RAM that we don't have enough for the allocator tests. At some point, we should refactor the test suite to allow subsets of the test suite to be built. Add test for large objects. Fixes #230
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 text was updated successfully, but these errors were encountered: