From: Marc Zyngier <maz@kernel.org>
To: linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev
Cc: Fuad Tabba <tabba@google.com>, Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oupton@kernel.org>,
Zenghui Yu <yuzenghui@huawei.com>
Subject: [PATCH 0/9] arm64: Fully disable configured-out features
Date: Thu, 19 Feb 2026 19:55:23 +0000 [thread overview]
Message-ID: <20260219195533.2455736-1-maz@kernel.org> (raw)
Fuad recently reported [1] that when support for FEAT_S1POE is
disabled, but that the HW supports it, the sanitised idreg still show
the value the HW expose, even if this is hidden from userspace. This
ended up advertising S1POE to guests, without the state being
correctly switched. Huhum.
We have a point-fix for this, but it would be good to address the
whole class of similar issues which affect PAuth, SVE, SME, GCS, MTE
and BTI, on top of S1POE. Not we currently leak state S1POE-style, but
we're just pretty lucky. Hence this.
This series tries to align the behaviour of a config option being not
selected with that of the corresponding runtime option (arm64.noFEAT),
with the exception of BTI (but I'm not married with that particular
aspect).
There is a lot more that could be done (Mark has a lot of ideas on
that front), but I wanted to get this out and get the discussion
going.
Another thing is that the proliferation of config options is getting
in the way of maintainability, and at some point, we'll have to pick
our battles. I appreciate that some embedded uses rely on "tinyfying"
the kernel, but maybe we should think of introducing something less
granular, and have KVM to select that (the argument being that if you
want the smallest possible kernel, you don't want anything virt).
Anyway, 'nuf ranting. Patches on top of 6.19.
[1] https://lore.kernel.org/all/20260213143815.1732675-2-tabba@google.com
Marc Zyngier (9):
arm64: Add logic to fully remove features from sanitised id registers
arm64: Convert CONFIG_ARM64_PTR_AUTH to FTR_CONFIG()
arm64: Convert CONFIG_ARM64_SVE to FTR_CONFIG()
arm64: Convert CONFIG_ARM64_SME to FTR_CONFIG()
arm64: Convert CONFIG_ARM64_GCS to FTR_CONFIG()
arm64: Convert CONFIG_ARM64_MTE to FTR_CONFIG()
arm64: Convert CONFIG_ARM64_POE to FTR_CONFIG()
arm64: Convert CONFIG_ARM64_BTI to FTR_CONFIG()
arm64: Remove FTR_VISIBLE_IF_IS_ENABLED()
arch/arm64/include/asm/cpufeature.h | 13 ++--
arch/arm64/kernel/cpufeature.c | 117 +++++++++++++++-------------
2 files changed, 72 insertions(+), 58 deletions(-)
--
2.47.3
next reply other threads:[~2026-02-19 19:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-19 19:55 Marc Zyngier [this message]
2026-02-19 19:55 ` [PATCH 1/9] arm64: Add logic to fully remove features from sanitised id registers Marc Zyngier
2026-02-20 8:36 ` Fuad Tabba
2026-02-20 10:09 ` Marc Zyngier
2026-02-20 11:06 ` Fuad Tabba
2026-02-20 14:52 ` Marc Zyngier
2026-02-20 15:36 ` Fuad Tabba
2026-02-23 9:48 ` Marc Zyngier
2026-02-23 18:18 ` Suzuki K Poulose
2026-02-19 19:55 ` [PATCH 2/9] arm64: Convert CONFIG_ARM64_PTR_AUTH to FTR_CONFIG() Marc Zyngier
2026-02-19 19:55 ` [PATCH 3/9] arm64: Convert CONFIG_ARM64_SVE " Marc Zyngier
2026-02-19 19:55 ` [PATCH 4/9] arm64: Convert CONFIG_ARM64_SME " Marc Zyngier
2026-02-19 19:55 ` [PATCH 5/9] arm64: Convert CONFIG_ARM64_GCS " Marc Zyngier
2026-02-19 19:55 ` [PATCH 6/9] arm64: Convert CONFIG_ARM64_MTE " Marc Zyngier
2026-02-19 19:55 ` [PATCH 7/9] arm64: Convert CONFIG_ARM64_POE " Marc Zyngier
2026-02-19 19:55 ` [PATCH 8/9] arm64: Convert CONFIG_ARM64_BTI " Marc Zyngier
2026-02-19 19:55 ` [PATCH 9/9] arm64: Remove FTR_VISIBLE_IF_IS_ENABLED() Marc Zyngier
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=20260219195533.2455736-1-maz@kernel.org \
--to=maz@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=mark.rutland@arm.com \
--cc=oupton@kernel.org \
--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