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

Jump to bottom

improvements to Zcheripte text #451

Merged
merged 5 commits into from
Nov 20, 2024
Merged

improvements to Zcheripte text #451

Changes from 4 commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
7f30edc
improvements to Zcheripte text
tariqkurd-repo Nov 13, 2024
b996bd9
move RV64 specifier
tariqkurd-repo Nov 13, 2024
42685e3
update wording
tariqkurd-repo Nov 14, 2024
51bbc9e
add note about exception handler
tariqkurd-repo Nov 14, 2024
3158daa
tie hardware enabling to Svade/Svadu
tariqkurd-repo Nov 15, 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
15 changes: 11 additions & 4 deletions src/cheri-pte-ext.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
[#section_sv_cheri]
[#cheri_pte_ext]
== "{cheri_pte_ext_name}" Extension for CHERI Page-Based Virtual-Memory Systems
== "{cheri_pte_ext_name}" Extension for CHERI Page-Based Virtual-Memory Systems (RV64 only)

CHERI is a security mechanism that is generally orthogonal to page-based
virtual-memory management as defined in cite:[riscv-priv-spec].
Expand All @@ -10,9 +10,15 @@ capabilities in memory at the page granularity. For this reason, the
{cheri_pte_ext_name} extension adds new bits to RISC-V's Page Table Entry (PTE)
format.

Implementing any virtual memory translation scheme (_Sv39_, _Sv48_ or _Sv57_) and {cheri_base_ext_name} requires {cheri_pte_ext_name} to be implemented.
NOTE: There is no explicit mechanism for enabling or disabling {cheri_pte_ext_name}. A VM-enabled legacy (non-CHERI) OS running in {cheri_int_mode_name} will not load or store capabilities, and so the default state of CW=0 causing loaded capabilities to have their tags cleared, and stored capabilities with their tags set to cause a page fault, won't occur.

NOTE: There is no explicit mechanism for enabling or disabling {cheri_pte_ext_name}. A VM-enabled legacy (non-CHERI) OS running in {cheri_int_mode_name} will not load or store capabilities, and so the default state of CW=0 causing loaded capabilities to have their tags cleared, and stored capabilities with their tags set to cause a page fault, won't occur. A CHERI-aware OS running a VM-enabled OS is required to support {cheri_pte_ext_name}, and the minimum level of support is to set CW to 1 in all PTEs and leave <<sstatusreg_pte,sstatus>>.CRG and CRG in all PTEs set to 0, which will allow capabilities with their tags set to be loaded and stored successfully.
A CHERI-aware OS running a VM-enabled OS is strongly recommended to support {cheri_pte_ext_name}, and the minimum level of support is to set CW to 1 in all PTEs intended for storing capabilities (i.e. anonymous mappings) and leave <<sstatusreg_pte,sstatus>>.CRG and CRG in all PTEs set to 0, which will allow capabilities with their tags set to be loaded and stored successfully.

Therefore when implementing any RV64 virtual memory translation scheme (_Sv39_, _Sv48_ or _Sv57_) and {cheri_base_ext_name}, implementing {cheri_pte_ext_name} is strongly recommended.

NOTE: It is possible to detect the presence of {cheri_pte_ext_name} in software, by configuring a page table entry without programming CW and without setting <<sstatusreg_pte,sstatus>>.CRG, and testing for an exception on storing a tagged capability.

NOTE: _Sv32_ (for RV32) does not have any spare PTE bits, and so this extension cannot be implemented.

=== Limiting Capability Propagation

Expand Down Expand Up @@ -156,7 +162,8 @@ bit value of the capability read. This will introduce additional traps during re

^2^ The choice here follows the pattern of whether to implement the _Svade_ extension
to take page-fault exceptions for A and D PTE bit state changes, or whether to implement
a hardware updating mechanism.
a hardware updating mechanism. Software should implement support for a page fault in these cases
which will not be used if the hardware mechanism is implemented.

[#xstatus_pte]
=== Extending the Supervisor (sstatus) and Virtual Supervisor (vsstatus) Status Registers
Expand Down
Loading