Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allocator-test: probe revocation in more places #422

Merged
merged 2 commits into from
Jan 17, 2025

Conversation

nwf
Copy link
Member

@nwf nwf commented Jan 15, 2025

Explicitly test for revocation in all of globals, the stack, and the trusted stack.

@nwf
Copy link
Member Author

nwf commented Jan 16, 2025

This also needs a test of capabilities in static shared objects, which are like globals but are not within CGPs.

@rmn30 rmn30 force-pushed the nwf/202501-more_revoker_tests branch from 301ab8b to 3a0dbf4 Compare January 16, 2025 23:34
Copy link
Member Author

@nwf nwf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I cannot approve my own PR, but thank you for seeing the work through to the end. This LGTM.

@rmn30 rmn30 force-pushed the nwf/202501-more_revoker_tests branch from bc71a86 to 0e99407 Compare January 17, 2025 10:12
@rmn30 rmn30 force-pushed the nwf/202501-more_revoker_tests branch from 0e99407 to 0a42574 Compare January 17, 2025 13:29
nwf and others added 2 commits January 17, 2025 13:30
The current confgurations of both software and hardware revokers are
missing some of these and need to be fixed.  Specifically the software
revoker is not scanning trusted stacks or static sealed caps and the
hardware revoker is not scanning any stacks.
Neither software or hardware revoker were scanning enough of memory,
as revealed by the tests in the previous commit. To fix this we move
all the mutable data (which needs to be swept) into a single contigous
range bounded by __revoker_scan_start and __export_mem_heap_end.

The software revoker is currently set up to scan multiple disjoint
regions (stack, heap etc) but we now only need to use one, which is
not the same as the hardware revoker. This revealed a problem in the
loader where it was not using imprecise set bounds as intended.
@rmn30 rmn30 force-pushed the nwf/202501-more_revoker_tests branch from 0a42574 to df9c9ef Compare January 17, 2025 13:30
@rmn30 rmn30 enabled auto-merge (rebase) January 17, 2025 13:37
@rmn30 rmn30 merged commit 7c12bd5 into main Jan 17, 2025
7 checks passed
@rmn30 rmn30 deleted the nwf/202501-more_revoker_tests branch January 17, 2025 13:40
nwf added a commit that referenced this pull request Jan 21, 2025
Ensure that the compiler loads the to be revoked pointer into a register
prior to releasing the main thread.  Otherwise, there is a chance that
we never hold an unrevoked copy in the register file.

Embarrassing fix to
#422
nwf added a commit that referenced this pull request Jan 21, 2025
Ensure that the compiler loads the to be revoked pointer into a register
prior to releasing the main thread.  Otherwise, there is a chance that
we never hold an unrevoked copy in the register file.

Embarrassing fix to
#422
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants