linux-kernel - Re: [PATCH v2 2/2] RISC-V: KVM: add KVM_CAP_RISCV_MP_STATE

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] [day] [month] [year] [list]

Message-ID: <CAAhSdy3j0Uf52hs+_gRxkROTA4sjMkLk1sMtv=XZWsyv15TBSw@mail.gmail.com>
Date: Sun, 11 May 2025 19:13:37 +0530
From: Anup Patel <anup@...infault.org>
To: Radim Krčmář <rkrcmar@...tanamicro.com>
Cc: Andrew Jones <ajones@...tanamicro.com>, kvm-riscv@...ts.infradead.org, 
	kvm@...r.kernel.org, linux-riscv@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, Atish Patra <atishp@...shpatra.org>, 
	Paul Walmsley <paul.walmsley@...ive.com>, Palmer Dabbelt <palmer@...belt.com>, 
	Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>
Subject: Re: [PATCH v2 2/2] RISC-V: KVM: add KVM_CAP_RISCV_MP_STATE_RESET

On Fri, May 9, 2025 at 7:27 PM Radim Krčmář <rkrcmar@...tanamicro.com> wrote:
>
> 2025-05-09T17:59:28+05:30, Anup Patel <anup@...infault.org>:
> > On Fri, May 9, 2025 at 5:49 PM Andrew Jones <ajones@...tanamicro.com> wrote:
> >> On Fri, May 09, 2025 at 05:33:49PM +0530, Anup Patel wrote:
> >> > On Fri, May 9, 2025 at 2:16 PM Radim Krčmář <rkrcmar@...tanamicro.com> wrote:
> >> > > 2025-05-09T12:25:24+05:30, Anup Patel <anup@...infault.org>:
> >> > > > On Thu, May 8, 2025 at 8:01 PM Radim Krčmář <rkrcmar@...tanamicro.com> wrote:
> >> > > >>  * Preserve the userspace initialized VCPU state on sbi_hart_start.
> >> > > >>  * Return to userspace on sbi_hart_stop.
> >> > > >
> >> > > > There is no userspace involvement required when a Guest VCPU
> >> > > > stops itself using SBI HSM stop() call so STRONG NO to this change.
> >> > >
> >> > > Ok, I'll drop it from v3 -- it can be handled by future patches that
> >> > > trap SBI calls to userspace.
> >> > >
> >> > > The lack of userspace involvement is the issue.  KVM doesn't know what
> >> > > the initial state should be.
> >> >
> >> > The SBI HSM virtualization does not need any KVM userspace
> >> > involvement.
> >> >
> >> > When a VCPU stops itself using SBI HSM stop(), the Guest itself
> >> > provides the entry address and argument when starting the VCPU
> >> > using SBI HSM start() without any KVM userspace involvement.
> >> >
> >> > In fact, even at Guest boot time all non-boot VCPUs are brought-up
> >> > using SBI HSM start() by the boot VCPU where the Guest itself
> >> > provides entry address and argument without any KVM userspace
> >> > involvement.
> >>
> >> HSM only specifies the state of a few registers and the ISA only a few
> >> more. All other registers have IMPDEF reset values. Zeros, like KVM
> >> selects, are a good choice and the best default, but if the VMM disagrees,
> >> then it should be allowed to select what it likes, as the VMM/user is the
> >> policy maker and KVM is "just" the accelerator.
> >
> > Till now there are no such IMPDEF reset values expected. We will
> > cross that bridge when needed. Although, I doubt we will ever need it.
>
> The IMPDEF issue already exists.  KVM resets scounteren to 7, but
> userspace wants it to be different, likely 0.

The scounteren set to 7 is temporary workaround which is supposed
to be removed once Guest Linux initializes scounteren correctly at
boot time. At this point in time we can remove this scounteren
workaround from KVM because the SBI PMU driver is initializing
scounteren correctly since many kernel releases.
(Refer, pmu_sbi_starting_cpu() in drivers/perf/riscv_pmu_sbi.c)

If we absolutely need a mechanism for userspace to provide custom
reset values of CSRs then we should use the existing ONE_REG
interface to define a new type using which CSR reset values can be
set at VM creation time. But, I still think we don't need such a
mechanism immediatly.

Regards,
Anup