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

Consider a zero-tags instructions for revocation #230

Open
tariqkurd-repo opened this issue May 2, 2024 · 3 comments
Open

Consider a zero-tags instructions for revocation #230

tariqkurd-repo opened this issue May 2, 2024 · 3 comments

Comments

@tariqkurd-repo
Copy link
Collaborator

tariqkurd-repo commented May 2, 2024

RISC-V defines CBO.ZERO which zeroes a full cache line, and so including the tags contained with it.
It seems that we can do better and only clear the tags on a cache line without touching the data, when running a revocation sweep.
How useful this is, is another matter - as for system's supporting AXI - there's no way of sending such a bus transaction, without also writing back the whole cache line including the data. However, once CHERI systems become more common then it's something we could work towards.

The definition of the instruction is simple - it's as CBO.ZERO but only tags are zeroed, data is unmodified.

@PeterRugg
Copy link
Contributor

It seems that we can do better and only clear the tags on a cache line without touching the data, when running a revocation sweep.

Hmm, this might be a little tricky: during heap revocation you need to look at the data to decide if it's a capability that points into a region that's been freed. That means you can't blindly clear the tag: you have to load the capability into the core to do the revocation bitmap lookup using its base. Even once you've confirmed it has been revoked, it still wouldn't be safe to use the tag zeroing instruction on that address, because someone else might have written a perfectly valid (non-revoked) capability to that address in between you loading it and zeroing its tag, causing a crash somewhere down the line.

That said, there are other instances (on free itself, and when revoking things in local/global setups) where you do just want to clear everything: I guess it's a question how often you are okay with leaking data but not capabilities.

The ISAv9 spec has this ("CClearTags") in the experimental section, and points out that it could be helpful to use it on free to remove any capabilities stored in freed memory (assuming you're not already zeroing it), to prevent you having to check all the capabilities in that memory during the revocation sweep.

@jonwoodruff
Copy link
Contributor

Just to add the obvious: stack zeroing could choose to do this as well.
How much benefit there is to clearing only tags rather than all of data I'll leave up to others.
From a CHERI compartmentalisation perspective, you only care that people don't get pointers,
but, in general, software cares about other kinds of data leaking, and so might just want to zero.
If we're a little fuzzy about whether tag clearing is going to certainly be faster than zeroing, then it might be worth waiting on this.

@davidchisnall
Copy link

If you are designing a high-performance microarchitecture, zeroing data and tags is a lot faster than zeroing just tags.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants