Allocator test #375
Open
Allocator test #375
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hmm, didn't expect it to pull all my private commits in, sorry. |
|
If you cherry pick the commit you want to a new branch and then force push the result to the branch this PR is from it should do the right thing. |
sleffler
force-pushed
the
allocator_test
branch
from
38e5b54 to
e178c0e
Compare
|
That ("Heap capability still valid after releasing last claim") at a glance could be the first time the RTOS tests depend on agreement between the RTOS heap allocator's understanding of the revocation bitmap's location and corresponding base address and the load barrier's understanding of the same things (in the core implementation; see cheriot-sail's for example). While it is entirely possible that there is a bug in the allocator -- it's big, less carefully audited than the switcher (so far), and there have been quarantine/revocation related bugs before -- it'd be good to check that your target's board definition file has the right values. FWIW, if I tweak the |
|
Thank you, might be the revokable_memory_start; didn't know about that.
FWIW the board config is here
<https://opensecura.googlesource.com/3p/cheriot-rtos/+/refs/heads/master/sdk/boards/sencha.json>
.
I was under the impression the heap should not overlap code memory; how
does that work? (e.g. does the allocator find the end of pre-allocated
memory?)
…On Thu, Dec 12, 2024 at 12:45 PM Nathaniel Wesley Filardo < ***@***.***> wrote:
That ("Heap capability still valid after releasing last claim") at a
glance could be the first time the RTOS tests depend on agreement between
the RTOS heap allocator's understanding of the revocation bitmap's
location
<https://github.com/CHERIoT-Platform/cheriot-rtos/blob/5b83b7b40803a119129eb450d3670d38baa767c0/sdk/core/allocator/revoker.h#L98>
and corresponding base address
<https://github.com/CHERIoT-Platform/cheriot-rtos/blob/5b83b7b40803a119129eb450d3670d38baa767c0/sdk/xmake.lua#L433-L440>
and the load barrier's understanding of the same things (in the core
implementation; see cheriot-sail's
<https://github.com/CHERIoT-Platform/cheriot-sail/blob/2015e1cc9b2ebe703340eab25a47fedd65f753af/src/cheri_mem.sail#L81-L105>
for example).
While it is entirely possible that there is a bug in the allocator -- it's
big, less carefully audited than the switcher (so far), and there have been
quarantine/revocation related bugs before -- it'd be good to check that
your target's board definition file has the right values.
FWIW, if I tweak the sail board definition so that the heap is a hair
over 32K in size fails later, in test_revoke(), because its allocations
are too big. Further patches to follow.
—
Reply to this email directly, view it on GitHub
<#375 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABRM7IPPHPUADBKZIVKL53T2FHYVVAVCNFSM6AAAAABTO3EN7CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZZHE4DAMZUGM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
There is a symbol in the linker script for the start of the heap, which is usually just at the end of the static things. The revocable memory start marker is for the range that includes read-write globals and stacks as well as the heap. We have three kinds of memory with respect to temporal safety:
|
Small heaps (e.g. 32KB) cause test failures because the size of a "big allocation" is fixed. Use the heap size to do a better job. Change-Id: I24ad172f71c6c91c975a7cae94d29e3d7b43775f
This test wants to ensure that it cycles the heap, but it doesn't need to allocate huge objects to do so in all cases. Scale the size of the objects used with the total heap.
|
@sleffler With these four changes, the test (and, indeed, the full test suite) passes on a |
|
With your changes (and cheriot-rtos @ c633c64) I'm now failing in test_claims: Board config (w/ 32KB heap) is here: https://opensecura.googlesource.com/3p/cheriot-rtos/+/refs/heads/master/sdk/boards/sencha.json. You talked about wanting a full instruction trace. Lmk if that's still the case. I don't think it matters but testing was with mpact-cheriot (+renode). |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have a target platform where the heap is 32KB. I want to run the test suite but the allocator test fails because the current (fixed) BigAllocSize is too big. This change calculates BigAllocSize from the heap size. The change works for the sail board config but not my target w/ 32KB of heap:
Don't immediately see the problem so looking for help...