linux-kernel - Re: [PATCH v3 9/9] RISC-V: KVM: Upgrade the supported SBI version to 3.0

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <DACVBRLJ5MMV.1COZ83HBMUD6A@ventanamicro.com>
Date: Tue, 03 Jun 2025 13:40:30 +0200
From: Radim Krčmář <rkrcmar@...tanamicro.com>
To: "Atish Patra" <atish.patra@...ux.dev>, "Andrew Jones"
 <ajones@...tanamicro.com>
Cc: "Anup Patel" <anup@...infault.org>, "Will Deacon" <will@...nel.org>,
 "Mark Rutland" <mark.rutland@....com>, "Paul Walmsley"
 <paul.walmsley@...ive.com>, "Palmer Dabbelt" <palmer@...belt.com>,
 "Mayuresh Chitale" <mchitale@...tanamicro.com>,
 <linux-riscv@...ts.infradead.org>, <linux-arm-kernel@...ts.infradead.org>,
 <linux-kernel@...r.kernel.org>, <kvm@...r.kernel.org>,
 <kvm-riscv@...ts.infradead.org>, "linux-riscv"
 <linux-riscv-bounces@...ts.infradead.org>
Subject: Re: [PATCH v3 9/9] RISC-V: KVM: Upgrade the supported SBI version
 to 3.0

2025-05-30T12:29:30-07:00, Atish Patra <atish.patra@...ux.dev>:
> On 5/30/25 4:09 AM, Radim Krčmář wrote:
>> 2025-05-29T11:44:38-07:00, Atish Patra <atish.patra@...ux.dev>:
>>> On 5/29/25 3:24 AM, Radim Krčmář wrote:
>>>> I originally gave up on the idea, but I feel kinda bad for Drew now, so
>>>> trying again:
>>> I am sorry if some of my replies came across in the wrong way. That was
>>> never
>>> the intention.
>> I didn't mean to accuse you, my apologies.  I agree with Drew's
>> positions, so to expand on a question that wasn't touched in his mail:
>>
>>>> Even if userspace wants SBI for the M-mode interface, security minded
>>> This is probably a 3rd one ? Why we want M-mode interface in the user
>>> space ?
>> It is about turning KVM into an ISA accelerator.
>>
>> A guest thinks it is running in S/HS-mode.
>> The ecall instruction traps to M-mode.  RISC-V H extension doesn't
>> accelerate M-mode, so we have to emulate the trap in software.
> We don't need to accelerate M-mode. That's the beauty of the RISC-V H 
> extension.

(It is a gap to me. :])

> The ISA is designed in such a way that the SBI is the interface between 
> the supervisor environment (VS/HS)
> and the supervisor execution environment (HS/M).

The ISA says nothing about the implementation of said interface.

Returning 42 in x21 as a response to an ecall with 0x10 in a7 and 0x3 in
a6 is perfectly valid RISC-V implementation that KVM currently cannot
virtualize.

>> The ISA doesn't say that M-mode means SBI.  We try really hard to have
>> SBI on all RISC-V, but I think KVM is taking it a bit too far.
>>
>> We can discuss how best to describe SBI, so userspace can choose to
>> accelerate the M-mode in KVM, but I think that the ability to emulate
>> M-mode in userspace should be provided.
> I am still trying to understand the advantages of emulating the M-mode 
> in the user space.
> Can you please elaborate ?

This thread already has a lot of them, so to avoid repeating them, I
have to go into quite niche use-cases:
When developing M-mode software on RISC-V (when RISC-V has more useful
implementations than QEMU), a developer might want to accelerate the
S/U-modes in KVM.
It is also simpler to implement an old SBI interface (especially with
bugs/quirks) if virtualization just executes the old M-mode binary.

Why must KVM prevent userspace from virtualizing RISC-V?

> I am assuming you are not hinting Nested virtualization which can be 
> achieved with existing
> ISA provided mechanisms and accelerated by SBI NACL.

Right, I am talking about virtualization of RISC-V, because I don't have
a crystal ball to figure out what users will want.