linux-kernel - [RFC PATCH v1 1/2] KVM: arm64: Allow BT field in 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: <20240612023553.127813-2-shahuang@redhat.com>
Date: Tue, 11 Jun 2024 22:35:51 -0400
From: Shaoqin Huang <shahuang@...hat.com>
To: Oliver Upton <oliver.upton@...ux.dev>,
	Marc Zyngier <maz@...nel.org>,
	kvmarm@...ts.linux.dev
Cc: Eric Auger <eauger@...hat.com>,
	Sebastian Ott <sebott@...hat.com>,
	Cornelia Huck <cohuck@...hat.com>,
	Shaoqin Huang <shahuang@...hat.com>,
	James Morse <james.morse@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu <yuzenghui@...wei.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org
Subject: [RFC PATCH v1 1/2] KVM: arm64: Allow BT field in ID_AA64PFR1_EL1 writable

When migrating from MtCollins to AmpereOne, the BT field value in
ID_AA64PFR1_EL1 register is different and not writable. This causes
the migration to fail.

The BT field means Branch Target Identification mechanism support in
AArch64 state. The value 0 means BT is not implemented, the value 1
means BT is implemented.

On MtCollins(Migration Src), the BT value is 0.
On AmpereOne(Migration Dst), the BT value is 1.

As it defined in the ftr_id_aa64dfr0, the samller value is safe. So if
we make the BT field writable, on the AmpereOne(Migration Dst) the BT
field will be overrided with value 0.

Signed-off-by: Shaoqin Huang <shahuang@...hat.com>
---
But there is a question, the ARM DDI mentions from Armv8.5, the only
permitted value is 0b01. Do you guys know if there are any consequence
if the userspace write value 0b0 into this field? Or we should restrict
that at some level, like in VMM or kernel level?
---
 arch/arm64/kvm/sys_regs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index c9f4f387155f..8e0ea62e14e1 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -2292,7 +2292,7 @@ static const struct sys_reg_desc sys_reg_descs[] = {
 		   ID_AA64PFR0_EL1_GIC |
 		   ID_AA64PFR0_EL1_AdvSIMD |
 		   ID_AA64PFR0_EL1_FP), },
-	ID_SANITISED(ID_AA64PFR1_EL1),
+	ID_WRITABLE(SYS_ID_AA64PFR1_EL1, ID_AA64PFR1_EL1_BT),
 	ID_UNALLOCATED(4,2),
 	ID_UNALLOCATED(4,3),
 	ID_WRITABLE(ID_AA64ZFR0_EL1, ~ID_AA64ZFR0_EL1_RES0),
-- 
2.40.1