-
Notifications
You must be signed in to change notification settings - Fork 637
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.
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
Add draft of Svukte extension #1564
base: main
Are you sure you want to change the base?
Conversation
Svkt provides a means to make user-mode accesses to supervisor memory raise page faults in constant time, mitigating attacks that attempt to discover the supervisor software's address-space layout. I plan to submit this as a fast-track soon.
Co-authored-by: Josep Sans <[email protected]> Signed-off-by: Andrew Waterman <[email protected]>
Changes: - Extension renamed from Svkt to Svukte - SVKT field renamed to UKTE - HUVKT field moved from henvcfg to hstatus - HUVKT field renamed to HUKTE
OK, what happens if the extension is enabled, the Ubit in the PTE is set ( so the access would be valid if the extension was disabled). Does that override the U-bit? Implicitly, it does, but I'd like to see that explicit (possibly in this extension spec, and/or in the the description of the U-bit in the spec section on the definition of the U-bit |
The basic premise of Svukte is to take advantage of the convention in all 64-bit OS that user mappings are in positive address space and supervisor mappings are in negative address space. An OS that create user mappings in negative address space - even a single mapping - cannot turn on Svukte or the OS has to provide an emulation. For instance, for x86 based Linux legacy vDSO were located in negative address space and when LASS was introduced the OS provided emulation for such legacy vDSO. Non legacy vDSO on x86 and vDSO on RISC-V are located in positive address space. The point of Svukte is to fault on user access to negative addresses without consulting the address translation caches or doing implicit accesses to the page tables. So I think the state of the U bit is a don't care for this extension. For that matter the PTE itself may not be valid at all. |
I understand that convention of supervisor mappings in negative VA space.
I agree that *implicitly* the state of the U-bit ( or the validity of the
PTE entry) is a don't care.
I am just saying that it should be *explicit*, and not require a careful
reading.
There is nothing in the spec that says that PTE entries *must* not be
fetched - just that, if they are accessed, the amount of time to get to the
leaf PTE should be constant
(it isn't clear how time is measured: realtime, #cycles, etc - but my
assumption is however SW could measure it).
There is nothing in the spec that says an OS that allows U-mode mappings in
negative address space cannot (or must-not) turn on Svukte.
Bad things may (or may not) happen if it does (as Ved points out), but
certainly there is no HW enforcement.
There is nothing that prevents describing the obvious implementation
(short circuiting the translation process) into the spec
( or even making it a requirement if it is that obvious and simple).
instead of making all implementors puzzle it out / re-invent it from first
principles.
…On Wed, Oct 9, 2024 at 11:44 AM Ved Shanbhogue ***@***.***> wrote:
OK, what happens if the extension is enabled, the Ubit in the PTE is set (
so the access would be valid if the extension was disabled). Does that
override the U-bit? Implicitly, it does, but I'd like to see that explicit
(possibly in this extension spec, and/or in the the description of the
U-bit in the spec section on the definition of the U-bit
The basic premise of Svukte is to take advantage of the convention in all
64-bit OS that user mappings are in positive address space and supervisor
mappings are in negative address space. An OS that create user mappings in
negative address space - even a single mapping - cannot turn on Svukte or
the OS has to provide an emulation. For instance, for x86 based Linux
legacy vDSO were located in negative address space and when LASS was
introduced the OS provided emulation for such legacy vDSO. Non legacy vDSO
on x86 and vDSO on RISC-V are located in positive address space. The point
of Svukte is to fault on user access to negative addresses without
consulting the address translation caches or doing implicit accesses to the
page tables.
So I think the state of the U bit is a don't care for this extension. For
that matter the PTE itself may not be valid at all.
—
Reply to this email directly, view it on GitHub
<#1564 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJVI46WBNAB3PIF7OJDZ2V2RXAVCNFSM6AAAAABLNSDROGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBTGA2TQNBYGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
OK, I'll make it explicit. |
I would interpret "user-mode accesses to supervisor memory" to mean "where
the U-bit is zero".
"supervisor memory" is not a RISC-V architectural definition, except for
the above.
If there is an obvious implementation of this, why not just come right out
and describe it in a non-normative note?
I guarantee no one will firebomb your hourse if you do that (but if you
don't - no guarantees)
…On Wed, Oct 9, 2024 at 2:26 PM Andrew Waterman ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In src/supervisor.adoc
<#1564 (comment)>
:
> @@ -2270,6 +2279,45 @@ Invalid PTEs using a bounded timer, or making address-translation caches
coherent with store instructions that modify PTEs.
====
+[[sec:svukte]]
+== "Svukte" Extension for Address-Independent Latency of User-Mode Faults to Supervisor Addresses, Version 0.3
+
+The Svukte extension provides a means to make user-mode accesses to supervisor
+memory raise page faults in constant time, mitigating attacks that attempt to
I went with my version, but we can revisit this later if need be.
—
Reply to this email directly, view it on GitHub
<#1564 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHPXVJUV2XRYORWADJ75SYTZ2WNRNAVCNFSM6AAAAABLNSDROGVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGNJYGM2DMNJXGE>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
I don’t understand what you’re complaining about at this point. The note I added, that the PTE contents don’t matter, is even stronger than the thing you asked for! |
Hey everyone, just to piggy back on @allenjbaum comment, as I share the same opinion. I also misinterpreted the text on my first reading, and thought the hart would have to check the U bit on the PTE on every U-mode access and deliver an exception in constant-time (even though an implementation like this would be possible). However, after the presentation at the Security HC meeting, I now understand the extension much better. The desired final implementation is to AND three bits: vaddr[2^SXLEN-1], priv == u-mode, and senvcfg.UKTE (or the equivalent for the guest). I think it would be immensely helpful to add this short sentence as an implementation hint to the reader. |
Refer to the draft of svukte extension from: riscv/riscv-isa-manual#1564 Svukte provides a means to make user-mode accesses to supervisor memory raise page faults in constant time, mitigating attacks that attempt to discover the supervisor software's address-space layout. Signed-off-by: Fea.Wang <[email protected]> Reviewed-by: Frank Chang <[email protected]> Reviewed-by: Jim Shu <[email protected]>
Svkt provides a means to make user-mode accesses to supervisor memory raise page faults in constant time, mitigating attacks that attempt to discover the supervisor software's address-space layout.
I plan to submit this as a fast-track soon.