-
Notifications
You must be signed in to change notification settings - Fork 48
SGI support for capDL-tool #77
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
Merged
Merged
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
03e66a6
capDL-tool: fix printing for ARM irq handler caps
lsf37 0e2f236
SGI support for capDL-tool + loader + python
kent-mcleod 78efc72
capDL-tool: fix ASIDPool check
lsf37 ff2e6ab
capDL-tool: add an AArch64 test example
lsf37 280b0ca
CHANGES: add SGISignal cap entry
lsf37 36085a4
trivial: style update
lsf37 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Some comments aren't visible on the classic Files Changed page.
There are no files selected for viewing
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this is where the model deviates from reality and the properties are not part of the cap, but instead we pretend here they are elsewhere?
I don't understand what the advantage of that is, wouldn't that confuse object creation code when it creates zero sized SGI caps? Those won't be derivates of the UT cap either, so revoking the UT won't automatically clean up the SGI cap, which breaks normally valid assumptions. With this in mind, I really don't like pretending it's an object while it isn't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with you, for these caps it'd be conceptually nicer not to do that. Since capDL already deals with the issue for a lot of other cap types, there is infrastructure for fake objects, but no infrastructure for caps with content but without objects (only the control caps have no object in capDL).
For the concrete concerns, they are both fine and dealt with by the existing infrastructure for fake objects: the caps are not created from Untypeds and the loader knows that, so their derivation tree is not confused and revocation on UT is not supposed to clean up the object (the sgi_signal objects should not be under any untyped cover in the spec -- maybe I should add an explicit check for that). You can still specify an original cap and a derived cap (there are only two levels for SGISignalCap) and that works fine in the loader as well, it has an explicit
is_originalflag that is used for this.SGISignal caps can be revoked either by revoking on the IRQControl cap (which removes all of them, including IRQHandlers), or individually (that's what the second level is useful for) -- that's not specific to capDL, though, that's just how the IRQ-related caps work in the kernel.
So it does work fine with the right semantics, and in terms of capDL it does actually fit with how the rest is treated. It is awkward in the formalisation, because for other fake objects there is some kind of state in the kernel I can tie them to, but for these ones there is not, the data is only in the cap. So the indirection is going to be annoying in the proof. But it's better dealing with that only once than trying to build and debug a whole lot of infrastructure for creating caps in a different way to what the rest of the tools are used to.