-
Notifications
You must be signed in to change notification settings - Fork 35
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
detection of out of range top #521
Changes from 3 commits
b48c50e
055cc30
af587a1
d637272
45422c8
09fe69c
7418714
ec86701
5b2714d
1baa11a
aabff08
d4e2ed3
024e060
1ab7e6a
9d0d3cc
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -48,7 +48,8 @@ For <<CADD>>, the address is incremented by the value in | |
For <<CADDI>>, the address is incremented by the immediate value | ||
`imm`. | ||
|
||
include::malformed_clear_tag.adoc[] | ||
NOTE: This instruction sets `cd.tag=0` if `cs1` 's bounds are <<section_cap_malformed,malformed>>, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is ADD singled out? (Well, and SHxADD too, by virtue of their special fragment file not being updated) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. because they don't expand the bounds, so for cheaper implementation we're only including instructions which do expand the bounds There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. They still need to perform a representability check There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this is true, but don't expand the bounds. A functional unit which does CADD/CADDI doesn't need to do anything with the bounds, and the expansion is expensive just for this check. |
||
or if any of the reserved fields are set. | ||
|
||
Exceptions:: | ||
include::require_cre.adoc[] | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,2 +1,3 @@ | ||
NOTE: This instruction sets `cd.tag=0` if `cs1` 's bounds are <<section_cap_malformed,malformed>>, | ||
the <<section_cap_malformed_top_gt_inf_top,top bound is out of range>>, | ||
or if any of the reserved fields are set. |
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 don't understand this point. No such capability is given to you in the initial system state, so of course CBLD must ensure that it doesn't give you back one of these, but that's by virtue of it never being a subset of an existing capability?
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.
this is like the malformed bounds case, and so I'd like (at least the option of) detagging if such a thing is observed on either input of CBLD, just like we do for malformed bounds, reserved bits set etc...
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.
@tariqkurd-repo : Could you provide an example situation you are thinking that CBLD would produce a capability that has this property? (i.e. its top > 2^MXLEN and is tagged).
As @jrtc27 explained, CBLD will only ever output capabilities that have equal or smaller bounds than the input capability to maintain the property that software cannot gain permissions it did not have. So, if at reset the most permissive/powerful capability provided to software is the infinite capability, then CBLD should never return a capability that is tagged and has top > infinite_cap.top.
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.
These are currently (mostly) undocumented malformed bounds cases, and there are many of them.
They can only be caused by fault injection or bugs e.g. the tag cache attaching the wrong tag, and so should be filtered out.
They are too expensive to detect directly from the bounds, but trivial if the bounds are expanded.
Strictly speaking nothing needs to change in the hardware as they are impossible cases, just like reserved bits set or bad permissions.
The objective is to get formal verification to work allowing any bit pattern against the design, and this is one of the awkard cases, so we need to choose an approach.