Add draft of Svukte extension #1564

aswaterman · 2024-07-25T01:46:52Z

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.

src/supervisor.adoc

allenjbaum · 2024-10-09T18:11:18Z

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 · 2024-10-09T18:44:21Z

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 · 2024-10-09T19:22:51Z

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 · 2024-10-09T21:22:28Z

OK, I'll make it explicit.

allenjbaum · 2024-10-10T07:04:37Z

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 · 2024-10-10T08:31:05Z

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 · 2024-10-10T17:57:40Z

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 <fea.wang@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com>

aswaterman · 2024-11-05T01:57:09Z

@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 · 2024-11-05T11:35:16Z

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

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 <fea.wang@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com>

https://lore.kernel.org/qemu-devel/20241108085239.2927152-1-fea.wang@sifive.com --- From: "Fea.Wang" <fea.wang@sifive.com> To: qemu-devel@nongnu.org, qemu-riscv@nongnu.org Cc: Palmer Dabbelt <palmer@dabbelt.com>, Alistair Francis <alistair.francis@wdc.com>, Bin Meng <bmeng.cn@gmail.com>, Weiwei Li <liwei1518@gmail.com>, Daniel Henrique Barboza <dbarboza@ventanamicro.com>, Liu Zhiwei <zhiwei_liu@linux.alibaba.com>, "Fea.Wang" <fea.wang@sifive.com> Subject: [PATCH v2 0/5] Introduce svukte ISA extension Date: Fri, 8 Nov 2024 16:52:34 +0800 Message-Id: <20241108085239.2927152-1-fea.wang@sifive.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2607:f8b0:4864:20::102b; envelope-from=fea.wang@sifive.com; helo=mail-pj1-x102b.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-riscv@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: <qemu-riscv.nongnu.org> List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-riscv>, <mailto:qemu-riscv-request@nongnu.org?subject=unsubscribe> List-Archive: <https://lists.nongnu.org/archive/html/qemu-riscv> List-Post: <mailto:qemu-riscv@nongnu.org> List-Help: <mailto:qemu-riscv-request@nongnu.org?subject=help> List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-riscv>, <mailto:qemu-riscv-request@nongnu.org?subject=subscribe> Errors-To: qemu-riscv-bounces+qemu-riscv=archiver.kernel.org@nongnu.org Sender: qemu-riscv-bounces+qemu-riscv=archiver.kernel.org@nongnu.org The Svukte ISA extension has been approved for fast-track development. https://lf-riscv.atlassian.net/browse/RVS-2977 And there are Linux patches for the Svukte that are under review. https://lore.kernel.org/kvm/20240920-dev-maxh-svukte-rebase-v1-0-7864a88a62bd@sifive.com/T/#mf70fcb22cd2987ad268c0efee9b8583197d3cb4f 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. Refer to the draft of svukte extension from: riscv/riscv-isa-manual#1564 * Refactor the code base-commit: 27652f9 [v1] * Add svukte extension Fea.Wang (5): target/riscv: Add svukte extension capability variable target/riscv: Support senvcfg[UKTE] bit when svukte extension is enabled target/riscv: Support hstatus[HUKTE] bit when svukte extension is enabled target/riscv: Check memory access to meet svuket rule target/riscv: Expose svukte ISA extension target/riscv/cpu.c | 2 ++ target/riscv/cpu_bits.h | 2 ++ target/riscv/cpu_cfg.h | 1 + target/riscv/cpu_helper.c | 57 +++++++++++++++++++++++++++++++++++++++ target/riscv/csr.c | 7 +++++ 5 files changed, 69 insertions(+) -- 2.34.1 Signed-off-by: GitHub Actions Bot <bot@github.com>

This is the extension for "Address-Independent Latency of User-Mode Faults to Supervisor Addresses". Spec: riscv/riscv-isa-manual#1564 The spec states that the `svukte` depends on `sv39`, but we don't have `sv39` yet, so I didn't add it to the implied list.

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 <fea.wang@sifive.com> Reviewed-by: Frank Chang <frank.chang@sifive.com> Reviewed-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>

https://lore.kernel.org/qemu-devel/20241112091423.2529583-1-fea.wang@sifive.com --- From: "Fea.Wang" <fea.wang@sifive.com> To: qemu-devel@nongnu.org, qemu-riscv@nongnu.org Cc: Palmer Dabbelt <palmer@dabbelt.com>, Alistair Francis <alistair.francis@wdc.com>, Bin Meng <bmeng.cn@gmail.com>, Weiwei Li <liwei1518@gmail.com>, Daniel Henrique Barboza <dbarboza@ventanamicro.com>, Liu Zhiwei <zhiwei_liu@linux.alibaba.com>, "Fea.Wang" <fea.wang@sifive.com> Subject: [PATCH v3 0/5] Introduce svukte ISA extension Date: Tue, 12 Nov 2024 17:14:18 +0800 Message-Id: <20241112091423.2529583-1-fea.wang@sifive.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=2607:f8b0:4864:20::434; envelope-from=fea.wang@sifive.com; helo=mail-pf1-x434.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: <qemu-devel.nongnu.org> List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>, <mailto:qemu-devel-request@nongnu.org?subject=unsubscribe> List-Archive: <https://lists.nongnu.org/archive/html/qemu-devel> List-Post: <mailto:qemu-devel@nongnu.org> List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help> List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>, <mailto:qemu-devel-request@nongnu.org?subject=subscribe> Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org The Svukte ISA extension has been approved for fast-track development. https://lf-riscv.atlassian.net/browse/RVS-2977 And there are Linux patches for the Svukte that are under review. https://lore.kernel.org/kvm/20240920-dev-maxh-svukte-rebase-v1-0-7864a88a62bd@sifive.com/T/#mf70fcb22cd2987ad268c0efee9b8583197d3cb4f 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. Refer to the draft of svukte extension from: riscv/riscv-isa-manual#1564 base-commit: 27652f9 [v3] * Fix some typos * Refine code by separating a function into two dedicated functions. * Follow the riscv,isa order [v2] * Refactor the code [v1] * Add svukte extension Fea.Wang (5): target/riscv: Add svukte extension capability variable target/riscv: Support senvcfg[UKTE] bit when svukte extension is enabled target/riscv: Support hstatus[HUKTE] bit when svukte extension is enabled target/riscv: Check memory access to meet svukte rule target/riscv: Expose svukte ISA extension target/riscv/cpu.c | 2 ++ target/riscv/cpu_bits.h | 2 ++ target/riscv/cpu_cfg.h | 1 + target/riscv/cpu_helper.c | 61 +++++++++++++++++++++++++++++++++++++++ target/riscv/csr.c | 7 +++++ 5 files changed, 73 insertions(+) -- 2.34.1 Signed-off-by: GitHub Actions Bot <bot@github.com>

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 <josepsansprats@gmail.com> Signed-off-by: Andrew Waterman <aswaterman@gmail.com>

Changes: - Extension renamed from Svkt to Svukte - SVKT field renamed to UKTE - HUVKT field moved from henvcfg to hstatus - HUVKT field renamed to HUKTE

ingallsj reviewed Jul 25, 2024

View reviewed changes

src/supervisor.adoc Outdated Show resolved Hide resolved

src/supervisor.adoc Outdated Show resolved Hide resolved

AndybnACT reviewed Jul 25, 2024

View reviewed changes