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

Compatibility of CHERI RISC-V versions in a single system #217

Open
andresag01 opened this issue Apr 24, 2024 · 1 comment
Open

Compatibility of CHERI RISC-V versions in a single system #217

andresag01 opened this issue Apr 24, 2024 · 1 comment
Labels
bug Something isn't working documentation Improvements or additions to documentation

Comments

@andresag01
Copy link
Collaborator

Implementations of different CHERI RISC-V ISA versions are not strictly compatible with each other. For example, an RV64 CPU implementing Zcheripurecap only would be a little confused if it got a capability with Mode=Legacy from another implementation that implements Zcheripurecap+Zcherilegacy -- at the very least, it would break the invariant that valid caps have all reserved bits set to zero.

Although unlikely, this situation would arise if someone decided to create a multi-core system where the cores do not all implement the same CHERI ISA.

The CHERI RISC-V spec needs to have normative text to cover these cases. I think the spec's position should be that all the CPUs in the system must implement the same version (and options) of the CHERI RISC-V ISA.

@andresag01 andresag01 added bug Something isn't working documentation Improvements or additions to documentation labels Apr 24, 2024
@PRugg-Cap
Copy link
Contributor

Worth mentioning that with #285, we're pretty close to being able to support this kind of thing.

For example, an RV64 CPU implementing Zcheripurecap only would be a little confused if it got a capability with Mode=Legacy from another implementation that implements Zcheripurecap+Zcherilegacy

These cores will happily be able to interact, even copy each other's capabilities, but still have the guarantee that code with only a PureCap sentry to it can only ever be run PureCap, since the other core would refuse to jump to the capability.

I'm not saying we want to support this, but worth keeping it in the back of our minds...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants