linux-kernel - Re: [PATCH v11 RESEND 9/9] arm64: armv8_deprecated: apply FEAT

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

Message-ID: <aXEEHm9KRmfqW2Kh@e129823.arm.com>
Date: Wed, 21 Jan 2026 16:51:42 +0000
From: Yeoreum Yun <yeoreum.yun@....com>
To: Will Deacon <will@...nel.org>
Cc: Mark Rutland <mark.rutland@....com>, Marc Zyngier <maz@...nel.org>,
	catalin.marinas@....com, broonie@...nel.org, oliver.upton@...ux.dev,
	miko.lenczewski@....com, kevin.brodsky@....com, ardb@...nel.org,
	suzuki.poulose@....com, lpieralisi@...nel.org,
	yangyicong@...ilicon.com, scott@...amperecomputing.com,
	joey.gouly@....com, yuzenghui@...wei.com, pbonzini@...hat.com,
	shuah@...nel.org, arnd@...db.de,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	kvmarm@...ts.linux.dev, kvm@...r.kernel.org,
	linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v11 RESEND 9/9] arm64: armv8_deprecated: apply FEAT_LSUI
 for swpX emulation.

On Wed, Jan 21, 2026 at 04:36:26PM +0000, Will Deacon wrote:
> On Wed, Jan 21, 2026 at 04:31:28PM +0000, Yeoreum Yun wrote:
> > On Wed, Jan 21, 2026 at 04:20:36PM +0000, Will Deacon wrote:
> > > On Wed, Jan 21, 2026 at 02:51:10PM +0000, Yeoreum Yun wrote:
> > > > > On Tue, Jan 20, 2026 at 05:59:47PM +0000, Yeoreum Yun wrote:
> > > > > > On second thought, while a CPU that implements LSUI is unlikely to
> > > > > > support AArch32 compatibility,
> > > > > > I don't think LSUI requires the absence of AArch32.
> > > > > > These two are independent features (and in fact our FVP reports/supports both).
> > > > >
> > > > > Did you have to configure the FVP specially for this or that a "default"
> > > > > configuration?
> > > > >
> > > > > > Given that, I'm not sure a WARN is really necessary.
> > > > > > Would it be sufficient to just drop the patch for swpX instead?
> > > > >
> > > > > Given that the whole point of LSUI is to remove the PAN toggling, I think
> > > > > we should make an effort to make sure that we don't retain PAN toggling
> > > > > paths at runtime that could potentially be targetted by attackers. If we
> > > > > drop the SWP emulation patch and then see that we have AArch32 at runtime,
> > > > > we should forcefully disable the SWP emulation but, since we don't actually
> > > > > think we're going to see this in practice, the WARN seemed simpler.
> > > >
> > > > TBH, I missed the FVP configuration option clusterX.max_32bit_el, which
> > > > can disable AArch32 support by setting it to -1 (default: 3).
> > > > Given this, I think it’s reasonable to emit a WARN when LSUI is enabled and
> > > > drop the SWP emulation path under that condition.
> > >
> > > I'm asking about the default value.
> > >
> > > If Arm are going to provide models that default to having both LSUI and
> > > AArch32 EL0 supported, then the WARN is just going to annoy people.
> > >
> > > Please can you find out whether or not that's the case?
> >
> > Yes. I said the deafult == 3 which means that allow to execute
> > 32-bit in EL0 to EL3 (IOW, ID_AA64PFR0_EL1.EL0 == 0b0010)
> > -- but sorry for lack of explanation.
> >
> > When I check the latest model's default option value related for this
> > based on FVP version 11.30
> > (https://developer.arm.com/Tools%20and%20Software/Fixed%20Virtual%20Platforms/Arm%20Architecture%20FVPs),
> >
> >   - cluster0.has_lsui=1 default = '0x1'    : Implement additional load and store unprivileged instructions (FEAT_LSUI).
> >   - cluster0.max_32bit_el=3 default = '0x3'    : Maximum exception level supporting AArch32 modes. -1: No Support for A32 at any EL, x:[0:3] - All the levels below supplied ELx supports A32 : [0xffffffffffffffff:0x3]
> >
> > So it would be a annoying to people.
>
> Right, so you can probably do something like setting the 'status'
> field of 'insn_swp' to INSN_UNAVAILABLE if we detect LSUI.

Thanks for your suggestion. That would be good.

--
Sincerely,
Yeoreum Yun