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

Split CRG functionality for U and S-modes #491

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open

Split CRG functionality for U and S-modes #491

Show file tree
Hide file tree
Changes from 6 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
129a484
Split sstatus.CRG into CRGS/CRGU
tariqkurd-repo Dec 17, 2024
a819544
rename CRGS/CRGU to SCRG/UCRG and add note about status.SUM
tariqkurd-repo Dec 18, 2024
f4e728e
delete sstatus.SCRG, make PTE.CW mandatory
tariqkurd-repo Jan 10, 2025
4fdcd70
two minor clarifications
tariqkurd-repo Jan 10, 2025
adc0255
simplify mstatus note
tariqkurd-repo Jan 10, 2025
732c2a8
remove pointless note
tariqkurd-repo Jan 10, 2025
1bbb4b9
Update src/cheri-pte-ext.adoc
tariqkurd-repo Jan 10, 2025
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
78 changes: 45 additions & 33 deletions src/cheri-pte-ext.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,25 +1,31 @@
[#section_sv_cheri]
[#cheri_pte_ext]
== "{cheri_pte_ext_name}" Extension for CHERI Page-Based Virtual-Memory Systems (RV64 only)
== Extending Page-Based Virtual-Memory Systems for CHERI (RV64 only), including "{cheri_pte_ext_name}"

CHERI is a security mechanism that is generally orthogonal to page-based
virtual-memory management as defined in cite:[riscv-priv-spec].
However, it is helpful in CHERI harts to extend RISC-V's virtual-memory
management to facilitate capability revocation and control the flow of
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.
NOTE: _Sv32_ (for RV32) does not have any spare PTE bits, and so no features from this chapter can 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.
In CHERI harts the Page Table Entry (PTE) format is extended to control the flow of capabilities in memory (see <<limit_cap_prop>>).
This is achieved by adding the PTE.CW bit described below and is a mandatory feature when any virtual memory translation scheme (_Sv39_, _Sv48_ or _Sv57_) is implemented on an RV64 system.
By default PTE.CW=0 which will prevent legacy OSs from being able to load or store tagged capabilities without software modification.

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.
Additionally the {cheri_pte_ext_name} extension adds the ability to perform capability revocation of user mode pages (see <<cap_revocation>>) by adding the PTE.CRG bit, and <<sstatusreg_pte,sstatus>>.UCRG as described below.

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: {cheri_pte_ext_name} is strongly recommended but not mandatory as a future version of this specification may specify an improved method.

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: There is no explicit mechanism for enabling or disabling {cheri_pte_ext_name}. Its presence can be tested for by probing the existence of <<sstatusreg_pte,sstatus>>.UCRG.

NOTE: _Sv32_ (for RV32) does not have any spare PTE bits, and so this extension cannot be implemented.
NOTE: A future version of this specification may include kernel revocation which may require an <<sstatusreg_pte,sstatus>>.SCRG bit.

The remainder of this chapter jointly specifies the behavior of PTE.CW, PTE.CRG and <<sstatusreg_pte,sstatus>>.UCRG.

NOTE: The description below assumes that {cheri_pte_ext_name} has been implemented.
If that is _not_ the case then PTE.CRG and <<sstatusreg_pte,sstatus>>.UCRG should be taken as read-only-zero for purpose of the description in the remainder of this chapter only.
tariqkurd-repo marked this conversation as resolved.
Show resolved Hide resolved
PTE.CRG and <<sstatusreg_pte,sstatus>>.UCRG remain reserved in this case.

The minimum level of PTE support is to set CW to 1 in all PTEs intended for storing capabilities (i.e. anonymous mappings) and leave <<sstatusreg_pte,sstatus>>.UCRG and CRG in all PTEs set to 0, which will allow capabilities with their tags set to be loaded and stored successfully.


[#limit_cap_prop]
=== Limiting Capability Propagation

Page table enforcement can allow the operating system to limit the flow
Expand All @@ -46,6 +52,7 @@ a natural solution.

^*^ _allocated using mmap_

[#cap_revocation]
=== Capability Revocation

Page table enforcement can accelerate concurrent capability revocation
Expand Down Expand Up @@ -112,7 +119,7 @@ cleared <<tags_cleared_by_permissions,due to lack of permissions>>.
of this state.
** When a capability store or AMO instruction is executed
and the tag bit of the capability being written is set, the
implementation sets the CW bit and assigns the CRG bit equal to <<sstatusreg_pte,sstatus>>.CRG.
implementation sets the CW bit and assigns the CRG bit equal to <<sstatusreg_pte,sstatus>>.UCRG.
+
The PTE update must be
atomic with respect to other accesses to the PTE, and must atomically check
Expand All @@ -135,21 +142,26 @@ When CW is set, the CRG bit indicates the current generation of the virtual memo
regards to the ongoing capability revocation cycle. Two schemes are permitted:

* A load page fault exception is raised when a capability load or AMO instruction is executed
with <<c_perm>> granted and the virtual page's CRG bit does not equal <<sstatusreg_pte,sstatus>>.CRG.
with <<c_perm>> granted and the virtual page's CRG bit does not equal <<sstatusreg_pte,sstatus>>.UCRG in user mode.
* A load page fault exception is raised when a capability load or AMO instruction is executed
with <<c_perm>> granted and the virtual page's CRG bit does not equal <<sstatusreg_pte,sstatus>>.CRG
with <<c_perm>> granted and the virtual page's CRG bit does not equal <<sstatusreg_pte,sstatus>>.UCRG in user mode.
and the capability read from memory optionally has its tag set^1^.

[[pte_cw_crg_load_summary]]
.Summary of Load CW and CRG behavior in the PTEs
[%autowidth,float="center",align="center",cols="<,<,<",options="header"]
[%autowidth,float="center",align="center",cols="<,<,<,<",options="header"]
|===
|PTE.CW |PTE.CRG |Load/AMO
| 0 | X | Clear loaded tag
| 1 |&#8800; <<sstatusreg_pte,sstatus>>.CRG | Page fault, or page fault if tag is set^1^
| 1 |= <<sstatusreg_pte,sstatus>>.CRG | Normal operation
|PTE.CW |Mode^1^ |PTE.CRG |Load/AMO
| 0 | S/U | X | Clear loaded tag
| 1 | U |&#8800; <<sstatusreg_pte,sstatus>>.UCRG | Page fault, or page fault if tag is set^1^
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
| 1 | U |&#8800; <<sstatusreg_pte,sstatus>>.UCRG | Page fault, or page fault if tag is set^1^
| 1 | U |&#8800; <<sstatusreg_pte,sstatus>>.UCRG | Page fault, or page fault if tag is set

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to merge these footnotes so that the ^1^ here refers to the ^1^ further down.

| 1 | U |= <<sstatusreg_pte,sstatus>>.UCRG | Normal operation
| 1 | S | X | Normal operation^2^
|===

^1^ This is the current privilege mode, not the effective mode of the access and so is not affected by <<sstatusreg_pte,sstatus>>.SUM.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think sstatus.SUM has anything to do with effective privilege mode, which regards mstatus.prv and mstatus.mpp. So I think this needs to be rephrased.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If mstatus.MPRV=1 then all data memory accesses are performed as if in mode mstatus.MPP. So if mstatus.MPP=01 (S) then sstatus.SUM applies to all M-mode's data memory accesses.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And it must be affected by SUM. It is vital that, when the kernel copies memory to/from userspace, it follows exactly the same restrictions as userspace. Otherwise you could use a system call as a gadget to copy a to-be-revoked capability from a not-yet-swept page to a swept one.

Copy link
Collaborator

@jrtc27 jrtc27 Jan 10, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is, whether UCRG is used or not must be a function solely of the U bit, not the current mode as well. (Either the access is being done from U-mode, in which case that's always going to be set, or it's not, in which case the effective mode must be S-mode, whether in S-mode or in M-mode via mstatus.MPRV, and for it not to be faulting unconditionally already in the base privileged spec sstatus.SUM must also be set)

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, you are right about the SUM bit for sure, so the " not affected by <<sstatusreg_pte,sstatus>>.SUM" is wrong. I think this is the first time we have page bits that only apply in user mode I think?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For RISC-V I believe so, yes

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok - so it should be the effective mode of the memory access instead - should be a simple text replacement.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The effective mode is still S-mode with SUM. SUM just determines whether or not S-mode accessing pages with the U bit faults. That's why I said:

That is, whether UCRG is used or not must be a function solely of the U bit, not the current mode as well.

No mention of "effective mode". If the U bit is set, CRG exists and UCRG is checked against. If the U bit is clear, there is no CRG bit. There does not need to be any mention of the mode, because that is both necessary and sufficient.

tariqkurd-repo marked this conversation as resolved.
Show resolved Hide resolved

^2^ A future version of this specification may check an SCRG bit in <<sstatusreg_pte,sstatus>> for kernel revocation.

[[pte_cw_crg_store_summary]]
.Summary of Store CW and CRG behavior in the PTEs
[%autowidth,float="center",align="center",cols="<,<,<",options="header"]
Expand Down Expand Up @@ -181,19 +193,16 @@ The decision about whether to take exceptions on capability stores with the tag
These cause PTE Accessed and Dirty updates to be done in software, via the exception handler, or by a hardware mechanism respectively.

* If only _Svade_ is implemented, or enabled through henvcfg.ADUE or menvcfg.ADUE, then take a page fault.
* If only _Svadu_ is implemented, or enabled through henvcfg.ADUE or menvcfg.ADUE, then do the hardware update of setting PTE.CW=1 and setting PTE.CRG=<<sstatusreg_pte,sstatus>>.CRG as described in <<section_extending_pte>>.
* If only _Svadu_ is implemented, or enabled through henvcfg.ADUE or menvcfg.ADUE, then do the hardware update of setting PTE.CW=1 and setting PTE.CRG=<<sstatusreg_pte,sstatus>>.UCRG as described in <<section_extending_pte>>.

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

The <<sstatusreg_pte,sstatus>> and <<vsstatusreg_pte,vsstatus>> CSRs are extended to include the new Capability Read Generation (CRG) bit as shown.

When V=1 <<vsstatusreg_pte,vsstatus>>.CRG is in effect.

<<mstatusreg_pte,mstatus>>.CRG also exists. Reading or writing it is equivalent to reading or writing <<sstatusreg_pte,sstatus>>.CRG.
When V=1 <<vsstatusreg_pte,vsstatus>>.UCRG is in effect.

NOTE: As there is no M-mode translation available in RISC-V, there is no current software use for <<mstatusreg_pte,mstatus>>.CRG.
It is _only_ included not to break the rule that <<sstatusreg_pte,sstatus>> is required to be a subset of <<mstatusreg_pte,mstatus>>.
<<mstatusreg_pte,mstatus>>.UCRG also exists. Reading or writing it is equivalent to reading or writing <<sstatusreg_pte,sstatus>>.UCRG.


[#mstatusreg_pte]
Expand Down Expand Up @@ -232,8 +241,9 @@ It is _only_ included not to break the rule that <<sstatusreg_pte,sstatus>> is r
{bits: 1, name: 'WPRI'},
{bits: 1, name: 'MPELP'},
{bits: 1, name: 'MDT'},
{bits: 19, name: 'WPRI'},
{bits: 1, name: 'CRG'},
{bits: 18, name: 'WPRI'},
{bits: 1, name: 'UCRG'},
{bits: 1, name: 'WPRI'},
{bits: 1, name: 'SD'},
], config:{lanes: 4, hspace:1024}}
....
Expand Down Expand Up @@ -262,8 +272,9 @@ It is _only_ included not to break the rule that <<sstatusreg_pte,sstatus>> is r
{bits: 1, name: 'SDT'},
{bits: 7, name: 'WPRI'},
{bits: 2, name: 'UXL[1:0]'},
{bits: 28, name: 'WPRI'},
{bits: 1, name: 'CRG'},
{bits: 27, name: 'WPRI'},
{bits: 1, name: 'UCRG'},
{bits: 1, name: 'WPRI'},
{bits: 1, name: 'SD'},
], config:{lanes: 4, hspace:1024}}
....
Expand All @@ -289,8 +300,9 @@ It is _only_ included not to break the rule that <<sstatusreg_pte,sstatus>> is r
{bits: 1, name: 'SUM'},
{bits: 12, name: 'WPRI'},
{bits: 2, name: 'UXL[1:0]'},
{bits: 28, name: 'WPRI'},
{bits: 1, name: 'CRG'},
{bits: 27, name: 'WPRI'},
{bits: 1, name: 'UCRG'},
{bits: 1, name: 'WPRI'},
{bits: 1, name: 'SD'}
], config:{lanes: 4, hspace:1024}}
....
4 changes: 2 additions & 2 deletions src/insns/load_exceptions.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,8 +25,8 @@ listed below; in this case, _CHERI data fault_ is reported in the <<mtval2>> or
+
If {cheri_pte_ext_name} is implemented, and virtual memory is enabled, then the state of
<<cheri_pte_ext,PTE>>.CW and <<cheri_pte_ext,PTE>>.CRG from the current virtual memory page,
together with <<sstatusreg_pte,sstatus>>.CRG may cause a CHERI <<cheri_pte_ext,PTE>> page fault exception
in addition to a normal RISC-V page fault exception.
together with <<sstatusreg_pte,sstatus>>.UCRG may cause a CHERI <<cheri_pte_ext,PTE>> page fault exception
in addition to a normal RISC-V page fault exception when operating in user mode.
See <<mtval2-page-fault>> for the exception reporting in this case.
+
:!load_res:
Expand Down
3 changes: 2 additions & 1 deletion src/insns/store_exceptions.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,8 @@ listed below; in this case, _CHERI data fault_ is reported in the <<mtval2>> or
+
If {cheri_pte_ext_name} is implemented, and virtual memory is enabled, then the state of
<<cheri_pte_ext,PTE>>.CW and <<cheri_pte_ext,PTE>>.CRG from the current virtual memory page may
cause a CHERI <<cheri_pte_ext,PTE>> page fault exception in addition to a normal RISC-V page fault.
cause a CHERI <<cheri_pte_ext,PTE>> page fault exception in addition to a normal RISC-V page fault
when operating in user mode.
See <<mtval2-page-fault>> for the exception reporting in this case.
+
:!store_cond:
Expand Down
Loading