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

vm requires pte scheme #447

Merged
merged 2 commits into from
Nov 13, 2024
+3 −1
Merged

vm requires pte scheme #447

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e75f2cb
vm requires pte scheme
tariqkurd-repo Nov 12, 2024
340aa30
add note about OSs
tariqkurd-repo Nov 12, 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
4 changes: 3 additions & 1 deletion src/cheri-pte-ext.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,9 @@ 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.

{cheri_pte_ext_name} requires at least one virtual memory translation scheme (_Sv39_, _Sv48_ or _Sv57_) to be implemented.
Implementing any virtual memory translation scheme (_Sv39_, _Sv48_ or _Sv57_) and {cheri_base_ext_name} requires {cheri_pte_ext_name} to be implemented.
Copy link
Collaborator

Choose a reason for hiding this comment

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

For sv32 we can't support this extension, so I don't think VM implies PTE extension. Not supporting the extension should be fine since it just allows capability loads/stores anywhere. I suggest reverting this line.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Sorry - I clearly merged this far too soon - the problem is what the software sees if ZcheriPTE isn't implemented, because PTE.CW will be 0 and sstatus.CRG will be 0.
if PTE.CW=0 then cap load/stores either tag clear or except, so they aren't allowed anywhere.
For RV32 you're right - the PTE bits dont exist - so this is all a non-argument.

But for RV64 - how can the software know whether to look at the CW and CRG bits? If a CHERI core supports Zcheripte and the software doesn't know about it - isn't it a problem? I think that PTE.CW will always be zero and so cap load/store won't work.

So it seemed cleaner to require it, then there's no ambiguity - but certainly - only for RV64.


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.
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is dangerous advice, any OS that followed it would let you store capabilities to things like shared memory (allowing capabilities to pass between address spaces) or file-backed pages (same problem as shared memory, but also it just doesn't make sense to do, and if the page is swapped out and back the tags will disappear).

Copy link
Collaborator

Choose a reason for hiding this comment

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

How about just adding "pages intended to store capabilities (i.e. anonymous mappings)" :

Suggested change
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.
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 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.

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 - I'll make a new PR - let's discuss there


=== Limiting Capability Propagation

Expand Down
Loading