vm requires pte scheme #447
Conversation
| {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. | ||
|
|
||
| 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. |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
How about just adding "pages intended to store capabilities (i.e. anonymous mappings)" :
| 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. |
There was a problem hiding this comment.
ok - I'll make a new PR - let's discuss there
|
Ok, please suggest an improvement to the text!
…On Wed, 13 Nov 2024, 11:39 Jessica Clarke, ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/cheri-pte-ext.adoc
<#447 (comment)>:
> @@ -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.
+
+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.
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).
—
Reply to this email directly, view it on GitHub
<#447 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOCTJAH3I5P5UDYM5XDTOBD2AM3A3AVCNFSM6AAAAABRTYF5USVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDIMZSHAZTMNBUHA>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
| @@ -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. | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
there's no provision in the spec for VM in capability mode without the PTE extension, so the path of least resistance is to require it.
fixes #448