caprevoke: remove store side revocation #1743
Closed
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
brooksdavis
force-pushed
the
caprevoke-remove-storeside
branch
from
e2328fa
to
c4811cf
Compare
brooksdavis
force-pushed
the
caprevoke-remove-storeside
branch
from
c4811cf
to
425487e
Compare
This test depends on store-side behavior which will be removed shortly.
Always revoke load-side. CHERI_REVOKE_FORCE_LOAD_SIDE and CHERI_REVOKE_FORCE_STORE_SIDE are no longer defined and currently ignored as flags. We should likely restrict flags to valids ones for the release.
Delete the CHERI_REVOKE_ST_SS_* states from the enum and remove all code that referenced them.
Nothing sets this any more so remove it and the code that depends on it.
This was a store-side specific flag so remove it.
We can now revoke 2^60 times more before the epoch counter wraps...
Drop the ls_ prefix as we're always doing load-side revocation. Add an comment on the cause of the goto since I spent quite a few minutes failing to parse the label.
We're always doing load-side revocation so there's no need to keep it.
We're always doing a load-side scan so drop the flag to indicate we're doing one.
This flag was unused so drop it.
More flags have been removed so renumber the remaining ones. It might make sense to remove VM_CHERI_REVOKE_BARRIERED as it's implemented, but unused. For now keep it as it's described as a debug flag.
The whole comment was store side focused with an aside about the possibility of load side revocation. Rewrite to be be purely load side.
Installing all kernels by their own name is useful, but not what we're merging so remove from the branch.
These are useful in the development branch long with cycle counts, but probably not something we want in production.
std.CHERI-CAPREVOKE doesn't do anyting useful without CHERI support.
Make GENERIC-MORELLO include std.CHERI-CAPREVOKE. Add -NOCAPREVOKE variants that disable CAPREVOKE entierly. To aid script transitions, retain -CAPREVOKE variants. Update them to assume they inherit CAPREVOKE from GENERIC-MORELLO.
GENERIC-MORELLO now enables CAPREVOKE so we don't need these.
Add the contents of std.CHERI-CAPREVOKE to GENERIC-MORELLO and remove std.CHERI-CAPREVOKE.
Make std.CHERI include std.CHERI-CAPREVOKE. Add -NOCAPREVOKE variants that disable CAPREVOKE entierly. To aid script transitions, retain -CAPREVOKE variants. Update them to assume they inherit CAPREVOKE from std.CHERI.
All non-NOCAPREVOKE kernels now enable CAPREVOKE so they are unneeded.
Add the contents of std.CHERI-CAPREVOKE to std.CHERI and remove std.CHERI-CAPREVOKE.
brooksdavis
force-pushed
the
caprevoke-remove-storeside
branch
from
425487e
to
a3426b9
Compare
|
We've merged caprevoke minus store-side revocation so this is OBE |
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.
This is a PR for CI aiming to include the contents which will be merged to dev in a partially manual manner. It will be rebased as I update caprevoke with tidying fixes and and merges looped back from dev.
Load side revocation is the future. This PR aims to remove all vestiges of store side resulting in a considerable less confusing state machine.