linux-kernel - [PATCH v2 0/2] VCPU reset fixes

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

Message-ID: <20250508142842.1496099-2-rkrcmar@ventanamicro.com>
Date: Thu,  8 May 2025 16:28:41 +0200
From: Radim Krčmář <rkrcmar@...tanamicro.com>
To: kvm-riscv@...ts.infradead.org
Cc: kvm@...r.kernel.org,
	linux-riscv@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	Anup Patel <anup@...infault.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>,
	Andrew Jones <ajones@...tanamicro.com>
Subject: [PATCH v2 0/2] VCPU reset fixes

Hello,

v2 abandons the idea of fixing current userspaces and adds a new
capability that uses MP_STATE to immediately trigger a KVM VCPU reset --
a single-purpose interface free of any unintended side effects is
desirable and MP_STATE is somewhat bendable, which avoids the need for a
new IOCTL.  It's very dirty, though, so I'm not happy with it.

I have prepared a preview QEMU implementation [1] and only did light
testing with kvm-unit-tests as I still expect a high-level discussion.

Because it didn't take much effort on top, v2 expands the goals --
userspace can now choose the same post-reset state for all VCPUs.
(This is achieved by returning from userspace on sbi_hart_stop; let me
 know if I should rather do that with another KVM capability.)

This series does not fully address the VCPU hot-unplug.
We still need a better KVM interface there, because the VCPU stopped by
sbi_hart_stop is still assumed to be present by sbi_hart_start.

I see roughly two options, with different drawbacks:
* add a new MP_STATE for the SBI HSM acceleration in KVM
* return to userspace even on sbi_hart_start and sbi_hart_get_status

(We might want to have a better interface for handing SBI in userspace
 anyway, so that could be handled later.)

v2 is based on kvm-riscv/riscv_kvm_queue, 376e3c0f8aa5 ("KVM: RISC-V:
remove unnecessary SBI reset state").

Most of the patches from v1 got merged, thanks Anup, so v2 only contains
the completely redesigned approach [2/2] and a minor code style
improvement that fell through the cracks when the patches got merged out
of order [1/2].

---
1: https://github.com/qemu/qemu/commit/dec042841f383c6a825b1642b86d9f585778a2e7

Radim Krčmář (2):
  KVM: RISC-V: reset smstateen in a better place
  RISC-V: KVM: add KVM_CAP_RISCV_MP_STATE_RESET

 Documentation/virt/kvm/api.rst        | 15 +++++++++++
 arch/riscv/include/asm/kvm_host.h     |  3 +++
 arch/riscv/include/asm/kvm_vcpu_sbi.h |  1 +
 arch/riscv/kvm/vcpu.c                 | 39 ++++++++++++++++-----------
 arch/riscv/kvm/vcpu_sbi.c             | 17 ++++++++++++
 arch/riscv/kvm/vcpu_sbi_hsm.c         |  7 ++++-
 arch/riscv/kvm/vcpu_sbi_system.c      |  3 ++-
 arch/riscv/kvm/vm.c                   | 13 +++++++++
 include/uapi/linux/kvm.h              |  1 +
 9 files changed, 82 insertions(+), 17 deletions(-)

-- 
2.49.0