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.

Sign up for GitHub

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

invalid address csr updates #456

Merged
merged 6 commits into from
Dec 6, 2024
Merged

invalid address csr updates #456

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
b1a705d
fix https://github.com/riscv/riscv-cheri/issues/455
tariqkurd-repo Nov 28, 2024
5738200
clarify that tag clearing is only needed if the address actually changes
tariqkurd-repo Nov 29, 2024
4b5928a
add some flexibility
tariqkurd-repo Dec 2, 2024
8924587
Update src/riscv-integration.adoc
tariqkurd-repo Dec 6, 2024
98a11f5
Update src/riscv-integration.adoc
tariqkurd-repo Dec 6, 2024
eb98561
make wording match the risc-v spec more closely
tariqkurd-repo Dec 6, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 15 additions & 4 deletions src/riscv-integration.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1188,17 +1188,28 @@ this section describes how invalid address handling must be supported in
{cheri_base_ext_name} when accessing CSRs, branching and jumping, and
accessing memory.

===== Accessing CSRs
===== Updating CSRs

The following procedure must be used when executing instructions, such
as <<CSRRW>>, that write a capability A to a CSR that cannot hold all invalid
addresses:
Some capability-holding CSRs need not be able to hold all invalid virtual addresses.
Prior to writing to those CSRs, implementations may convert an invalid address into some other invalid address that the CSR is capable of holding.
This is problematic for CHERI as updating the address may invalidate the bounds as a result, if the bounds are not those of the <<infinite-cap>> capability.

Some situations may require that a CSR may be updated to hold a capability with an invalid address:

* executing instructions, such as <<CSRRW>>
* hardware updates to CSRs such as storing the <<pcc>> (which becomes capability A) into
<<mepcc>>/<<sepcc>> etc. when taking an exception.

In order to satisfy the definitions of such CSRs and preserve capability system invariants, the following procedure must be used as part of write-back to the CSR:

. If A's address is invalid and A does not have infinite bounds (see
xref:section_cap_encoding[xrefstyle=short]), then A's tag is set to 0.
. Write the final (potentially modified) version of capability A to the CSR e.g.
<<mtvecc>>, <<mepcc>>, etc.

NOTE: When A's address is invalid and happens to match an invalid address which the CSR
can hold, then it is implementation defined whether to clear A's tag.

===== Branches and Jumps

Control transfer instructions jump or branch to a capability A which can be:
Expand Down
Loading