linux-kernel - Re: [PATCH 0/5] Enable hstateen bits lazily for the KVM RISC-V Guests

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: <D9QTOYMN362W.398FE9SQB0S4X@ventanamicro.com>
Date: Thu, 08 May 2025 15:45:03 +0200
From: Radim Krčmář <rkrcmar@...tanamicro.com>
To: "Atish Patra" <atish.patra@...ux.dev>, "Anup Patel"
 <anup@...infault.org>, "Atish Patra" <atishp@...shpatra.org>, "Paul
 Walmsley" <paul.walmsley@...ive.com>, "Palmer Dabbelt"
 <palmer@...belt.com>, "Alexandre Ghiti" <alex@...ti.fr>
Cc: <kvm@...r.kernel.org>, <kvm-riscv@...ts.infradead.org>,
 <linux-riscv@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
 "linux-riscv" <linux-riscv-bounces@...ts.infradead.org>
Subject: Re: [PATCH 0/5] Enable hstateen bits lazily for the KVM RISC-V
 Guests

2025-05-07T17:34:38-07:00, Atish Patra <atish.patra@...ux.dev>:
> On 5/7/25 7:36 AM, Radim Krčmář wrote:
>> 2025-05-06T11:24:41-07:00, Atish Patra <atish.patra@...ux.dev>:
>>> On 5/6/25 2:24 AM, Radim Krčmář wrote:
>>>> 2025-05-05T14:39:25-07:00, Atish Patra <atishp@...osinc.com>:
>>>>>                                                      This series extends
>>>>> those to enable to correpsonding hstateen bits in PATCH1. The remaining
>>>>> patches adds lazy enabling support of the other bits.
>>>> The ISA has a peculiar design for hstateen/sstateen interaction:
>>>>
>>>>     For every bit in an hstateen CSR that is zero (whether read-only zero
>>>>     or set to zero), the same bit appears as read-only zero in sstateen
>>>>     when accessed in VS-mode.
>>> Correct.
>>>
>>>> This means we must clear bit 63 in hstateen and trap on sstateen
>>>> accesses if any of the sstateen bits are not supposed to be read-only 0
>>>> to the guest while the hypervisor wants to have them as 0.
>>> Currently, there are two bits in sstateen. FCSR and ZVT which are not
>>> used anywhere in opensbi/Linux/KVM stack.
>> True, I guess we can just make sure the current code can't by mistake
>> lazily enable any of the bottom 32 hstateen bits and handle the case
>> properly later.
>
> I can update the cover letter and leave a comment about that.
>
> Do you want a additional check in sstateen 
> trap(kvm_riscv_vcpu_hstateen_enable_stateen)
> to make sure that the new value doesn't have any bits set that is not 
> permitted by the hypervisor ?

I wanted to prevent kvm_riscv_vcpu_hstateen_lazy_enable() from being
able to modify the bottom 32 bits, because they are guest-visible and
KVM does not handle them correctly -- it's an internal KVM error that
should be made obvious to future programmers.

>>> In case, we need to enable one of the bits in the future, does hypevisor
>>> need to trap every sstateen access ?
>> We need to trap sstateen accesses if the guest is supposed to be able to
>> control a bit in sstateen, but the hypervisor wants to lazily enable
>> that feature and sets 0 in hstateen until the first trap.
> Yes. That's what PATCH 4 in this series does.

I was thinking about the correct emulation.

e.g. guest sets sstateen bit X to 1, but KVM wants to handle the feature
X lazily, which means that hstateen bit X is 0.
hstateen bit SE0 must be 0 in that case, because KVM must trap the guest
access to bit X and properly emulate it.
When the guest accesses a feature controlled by sstateen bit X, KVM will
lazily enable the feature and then set sstateen and hstateen bit X.