linux-kernel - Re: [PATCH v5 0/4] Allow userspace to change ID_AA64PFR1

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: <86ttf8wnwz.wl-maz@kernel.org>
Date: Sun, 25 Aug 2024 17:46:36 +0100
From: Marc Zyngier <maz@...nel.org>
To: Shaoqin Huang <shahuang@...hat.com>
Cc: Oliver Upton <oliver.upton@...ux.dev>,
	kvmarm@...ts.linux.dev,
	Mark Brown <broonie@...nel.org>,
	Eric Auger <eauger@...hat.com>,
	Sebastian Ott <sebott@...hat.com>,
	Cornelia Huck <cohuck@...hat.com>,
	Catalin Marinas <catalin.marinas@....com>,
	James Morse <james.morse@....com>,
	kvm@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org,
	linux-kselftest@...r.kernel.org,
	Paolo Bonzini <pbonzini@...hat.com>,
	Shuah Khan <shuah@...nel.org>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Will Deacon <will@...nel.org>,
	Zenghui Yu <yuzenghui@...wei.com>
Subject: Re: [PATCH v5 0/4] Allow userspace to change ID_AA64PFR1_EL1

On Tue, 23 Jul 2024 08:19:59 +0100,
Shaoqin Huang <shahuang@...hat.com> wrote:
> 
> Hi guys,
> 
> This is another try to allow userspace to change ID_AA64PFR1_EL1, and we want to
> give userspace the ability to control the visible feature set for a VM, which
> could be used by userspace in such a way to transparently migrate VMs.


I think this looks OK now, thanks for going through the motions and
doing the right thing.

What is missing is similar handling for 32bit ID registers, but I'm
not sure we keen on going down that road -- machines capable of
running those are on their way out. This can be done later anyway,
should anyone care.

>
> The patch series have four part:
> 
> The first patch disable those fields which KVM doesn't know how to handle, so
> KVM will only expose value 0 of those fields to the guest.
> 
> The second patch check the FEAT_SSBS in guest IDREG instead of the cpu
> capability.
> 
> The third patch allow userspace to change ID_AA64PFR1_EL1, it only advertise the
> fields known to KVM and leave others unadvertise.
> 
> The fourth patch adds the kselftest to test if userspace can change the
> ID_AA64PFR1_EL1.
> 
> Besides, I also noticed there is another patch [1] which try to make the
> ID_AA64PFR1_EL1 writable. This patch [1] is try to enable GCS on baremental, and
> add GCS support for the guest. What I understand is if we have GCS support on
> baremental, it will be clear to how to handle them in KVM. And same for other
> fields like NMI, THE, DF2, MTEX.. At that time, they can be
> writable.

I expect that Broonie would look into this as part of his series.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.