Add draft of Svukte extension

[aswaterman]

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.

[allenjbaum]

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

[ved-rivos]

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.

[allenjbaum]

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: ***@***.***>

[aswaterman]

OK, I'll make it explicit.

[allenjbaum]

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: ***@***.***>

[aswaterman]

I don’t understand what you’re asking for at this point. The note I added, that the PTE contents don’t matter, is even stronger than the thing you asked for!

[lfiolhais]

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.

[aswaterman]

@lfiolhais after discussing offline with Allen, I did add another sentence to the NOTE that directly addresses the matter. (No TLB accessess or page-table walks occur, therefore implicitly, the U-bit can't be of relevance.)

[lfiolhais]

@aswaterman Thanks! I think it's better now.