From: Fuad Tabba <fuad.tabba@linux.dev>
To: Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>,
kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org
Cc: Joey Gouly <joey.gouly@arm.com>,
Steffen Eiden <seiden@linux.ibm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Zenghui Yu <yuzenghui@huawei.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Mark Brown <broonie@kernel.org>, Lorenzo Stoakes <ljs@kernel.org>,
Fuad Tabba <tabba@google.com>,
linux-kernel@vger.kernel.org
Subject: [PATCH v2] KVM: arm64: Only enable S1PIE and S1POE with the features they imply
Date: Sun, 18 Oct 2026 09:09:20 +0100 [thread overview]
Message-ID: <20261018080921.3942517-1-fuad.tabba@linux.dev> (raw)
The world switch skips PIR_EL1, PIRE0_EL1 and POR_EL1 for a guest
without TCR2, but KVM doesn't trap them for a guest with S1PIE or
S1POE. Userspace can hide TCR2 while leaving either visible, and such a
guest then accesses registers that are neither trapped nor switched.
Under VHE, that leaks values between guests. POR_EL1, which the host
kernel doesn't use, leaks between guests in every mode. On nVHE and
hVHE, pKVM included, the host's own EL1 registers are saved and restored
according to the running guest's features, so the host kernel resumes
with its stage-1 permissions taken from the guest's PIR_EL1 and
PIRE0_EL1.
As per the architecture, S1PIE and S1POE imply TCR2 and ATS1A, and
S1POE also implies HPDS. Only enable each for a guest that has the
features it implies. A guest that has S1PIE or S1POE without them still
sees the feature in its ID registers, but its accesses to that
feature's registers UNDEF.
Fixes: 70ed7238297fb ("KVM: arm64: Sanitise ID_AA64MMFR3_EL1")
Fixes: d4a89e5aee23e ("KVM: arm64: Expose S1PIE to guests")
Reported-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20260930-arm64-gcs-v21-2-3556644cd927@kernel.org
Suggested-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/86fqyn2che.wl-maz@kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
Changes in v2:
- Also require FEAT_HPDS for S1POE (Marc)
- Link to v1: https://lore.kernel.org/r/20261015153041.3770032-1-fuad.tabba@linux.dev
Based on Linux 7.3-rc3 (fd73f4a665989).
arch/arm64/kvm/config.c | 28 ++++++++++++++++++++++++----
1 file changed, 24 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c
index 1053676551aff..6d2650427c5fc 100644
--- a/arch/arm64/kvm/config.c
+++ b/arch/arm64/kvm/config.c
@@ -205,6 +205,7 @@ struct reg_feat_map_desc {
#define FEAT_MEC ID_AA64MMFR3_EL1, MEC, IMP
#define FEAT_HAFT ID_AA64MMFR1_EL1, HAFDBS, HAFT
#define FEAT_HDBSS ID_AA64MMFR1_EL1, HAFDBS, HDBSS
+#define FEAT_HPDS ID_AA64MMFR1_EL1, HPDS, IMP
#define FEAT_HPDS2 ID_AA64MMFR1_EL1, HPDS, HPDS2
#define FEAT_BTI ID_AA64PFR1_EL1, BT, IMP
#define FEAT_ExS ID_AA64MMFR0_EL1, EXS, IMP
@@ -280,6 +281,25 @@ static bool feat_anerr(struct kvm *kvm)
kvm_has_feat(kvm, ID_AA64MMFR3_EL1, SNERR, FEAT_ANERR));
}
+/*
+ * S1PIE and S1POE imply TCR2 and ATS1A, and S1POE also implies HPDS, but
+ * userspace can set them independently.
+ */
+static bool feat_s1pie(struct kvm *kvm)
+{
+ return (kvm_has_feat(kvm, FEAT_S1PIE) &&
+ kvm_has_feat(kvm, FEAT_TCR2) &&
+ kvm_has_feat(kvm, FEAT_ATS1A));
+}
+
+static bool feat_s1poe(struct kvm *kvm)
+{
+ return (kvm_has_feat(kvm, FEAT_S1POE) &&
+ kvm_has_feat(kvm, FEAT_TCR2) &&
+ kvm_has_feat(kvm, FEAT_ATS1A) &&
+ kvm_has_feat(kvm, FEAT_HPDS));
+}
+
static bool feat_sme_smps(struct kvm *kvm)
{
/*
@@ -393,10 +413,10 @@ static const struct reg_bits_to_feat_map hfgrtr_feat_map[] = {
NEEDS_FEAT(HFGRTR_EL2_nS2POR_EL1, FEAT_S2POE),
NEEDS_FEAT(HFGRTR_EL2_nPOR_EL1 |
HFGRTR_EL2_nPOR_EL0,
- FEAT_S1POE),
+ feat_s1poe),
NEEDS_FEAT(HFGRTR_EL2_nPIR_EL1 |
HFGRTR_EL2_nPIRE0_EL1,
- FEAT_S1PIE),
+ feat_s1pie),
NEEDS_FEAT(HFGRTR_EL2_nRCWMASK_EL1, FEAT_THE),
NEEDS_FEAT(HFGRTR_EL2_nTPIDR2_EL0 |
HFGRTR_EL2_nSMPRI_EL1,
@@ -474,10 +494,10 @@ static const struct reg_bits_to_feat_map hfgwtr_feat_map[] = {
NEEDS_FEAT(HFGWTR_EL2_nS2POR_EL1, FEAT_S2POE),
NEEDS_FEAT(HFGWTR_EL2_nPOR_EL1 |
HFGWTR_EL2_nPOR_EL0,
- FEAT_S1POE),
+ feat_s1poe),
NEEDS_FEAT(HFGWTR_EL2_nPIR_EL1 |
HFGWTR_EL2_nPIRE0_EL1,
- FEAT_S1PIE),
+ feat_s1pie),
NEEDS_FEAT(HFGWTR_EL2_nRCWMASK_EL1, FEAT_THE),
NEEDS_FEAT(HFGWTR_EL2_nTPIDR2_EL0 |
HFGWTR_EL2_nSMPRI_EL1,
--
2.39.5
next reply other threads:[~2026-10-18 8:09 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-18 8:09 Fuad Tabba [this message]
2026-10-18 17:37 ` [PATCH v2] KVM: arm64: Only enable S1PIE and S1POE with the features they imply Marc Zyngier
2026-10-18 18:52 ` Fuad Tabba
2026-10-19 7:31 ` Marc Zyngier
2026-10-19 8:49 ` Fuad Tabba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261018080921.3942517-1-fuad.tabba@linux.dev \
--to=fuad.tabba@linux.dev \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=seiden@linux.ibm.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox