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

Clarification on "valid capabilities" #310

Closed
jasonyu1996 opened this issue Jul 3, 2024 · 5 comments
Closed

Clarification on "valid capabilities" #310

jasonyu1996 opened this issue Jul 3, 2024 · 5 comments

Comments

@jasonyu1996
Copy link
Contributor

Chapter 2 mentions:

   If the tag is set, the capability is valid and can be dereferenced (contingent on checks such as permissions or bounds).

and

(see The address Section 2.2.6.3).
 and bounds must be representable in valid capabilities i.e. when the tag is set

So one would expect "valid capabilities = capabilities with tag set"

But in 2.2.6

A capability is malformed if its encoding does not describe a valid capability because its bounds cannot
be correctly decoded.

which suggests that a capability can be invalid because its bounds cannot be decoded, even if the tag is set.

The consequence is one doesn't know if this in 2.2.1 applies to tagged capabilities with non-decodable bounds:

All capabilities derived from invalid capabilities are
themselves invalid i.e. their tags are 0
@arichardson
Copy link
Collaborator

The "tag set, but bounds malformed" case should only be possible due to an error in the memory subsystem/bit flips, maybe we should more explicitly call out that these will not exist in a well-defined execution?

@jasonyu1996
Copy link
Contributor Author

The "tag set, but bounds malformed" case should only be possible due to an error in the memory subsystem/bit flips, maybe we should more explicitly call out that these will not exist in a well-defined execution?

I think the culprit is "A capability is malformed if its encoding does not describe a valid capability because its bounds cannot be correctly decoded" in 2.2.6. The reader would expect that sentence to be a definition of "malformed capabilities", which should be something like "A capability is malformed when its bounds cannot be correctly decoded." Whether it is a valid capability is irrelevant here. Also, it's not "because its bounds cannot be correctly decoded" that a malformed capability "does not describe a valid capability". In my understanding, a malformed capability cannot be valid (i.e., tagged) only because well-formedness is always enforced, rather than by definition.

@tariqkurd-repo
Copy link
Collaborator

In my understanding, a malformed capability cannot be valid (i.e., tagged) only because well-formedness is always enforced, rather than by definition.

Not quite, and this is something we've been working on very recently.
If a corrupted (tagged and malformed capability) is read by the memory system it will be propagated through stores, and register moves without modification.
Any instruction which needs to decode the bounds will take action, e.g. setting the result to 0 for GCBASE.

We didn't want to clean up bad caps as LC/SC/CMV should just propagate what's there to avoid complicating the micro-architecture.

@jasonyu1996
Copy link
Contributor Author

In my understanding, a malformed capability cannot be valid (i.e., tagged) only because well-formedness is always enforced, rather than by definition.

Not quite, and this is something we've been working on very recently. If a corrupted (tagged and malformed capability) is read by the memory system it will be propagated through stores, and register moves without modification. Any instruction which needs to decode the bounds will take action, e.g. setting the result to 0 for GCBASE.

We didn't want to clean up bad caps as LC/SC/CMV should just propagate what's there to avoid complicating the micro-architecture.

But the only source of malformed but tagged capabilities is errors in the memory subsystem or hardware bugs? The ISA level makes sure that tagged capabilities that can ever be created/derived are all well-formed right?

arichardson pushed a commit that referenced this issue Jul 16, 2024
This attempts to address #310 by clarifying the definition of "malformed
capabilities". The relationship between valid capabilities and malformed
capabilities is now separately mentioned as what CHERI instructions
check and enforce.
@arichardson
Copy link
Collaborator

I believe this is now fixed - please reopen it if not.

tariqkurd-repo pushed a commit to tariqkurd-repo/riscv-cheri that referenced this issue Oct 9, 2024
This attempts to address riscv#310 by clarifying the definition of "malformed
capabilities". The relationship between valid capabilities and malformed
capabilities is now separately mentioned as what CHERI instructions
check and enforce.
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

No branches or pull requests

3 participants