Apply the FEAT_LSUI instruction to emulate the deprecated swpX
instruction, so that toggling of the PSTATE.PAN bit can be removed when
LSUI-related instructions are used.
Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com>
---
arch/arm64/kernel/armv8_deprecated.c | 77 +++++++++++++++++++++++++---
1 file changed, 71 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/armv8_deprecated.c b/arch/arm64/kernel/armv8_deprecated.c
index d15e35f1075c..b8e6d71f766d 100644
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -13,6 +13,7 @@
#include <linux/uaccess.h>
#include <asm/cpufeature.h>
+#include <asm/lsui.h>
#include <asm/insn.h>
#include <asm/sysreg.h>
#include <asm/system_misc.h>
@@ -86,13 +87,77 @@ static unsigned int __maybe_unused aarch32_check_condition(u32 opcode, u32 psr)
* Rn = address
*/
+/* Arbitrary constant to ensure forward-progress of the loop */
+#define __SWP_LOOPS 4
+
+#ifdef CONFIG_AS_HAS_LSUI
+static __always_inline int
+__lsui_user_swp_asm(unsigned int *data, unsigned int addr)
+{
+ int err = 0;
+ unsigned int temp;
+
+ asm volatile("// __lsui_user_swp_asm\n"
+ __LSUI_PREAMBLE
+ "1: swpt %w1, %w2, [%3]\n"
+ " mov %w1, %w2\n"
+ "2:\n"
+ _ASM_EXTABLE_UACCESS_ERR(1b, 2b, %w0)
+ : "+r" (err), "+r" (*data), "=&r" (temp)
+ : "r" ((unsigned long)addr)
+ : "memory");
+
+ return err;
+}
+
+static __always_inline int
+__lsui_user_swpb_asm(unsigned int *data, unsigned int addr)
+{
+ u8 i, idx;
+ int err = -EAGAIN;
+ u64 __user *addr_al;
+ u64 oldval;
+ union {
+ u64 var;
+ u8 raw[sizeof(u64)];
+ } newval, curval;
+
+ idx = addr & (sizeof(u64) - 1);
+ addr_al = (u64 __user *)ALIGN_DOWN(addr, sizeof(u64));
+
+ for (i = 0; i < __SWP_LOOPS; i++) {
+ if (get_user(oldval, addr_al))
+ return -EFAULT;
+
+ curval.var = newval.var = oldval;
+ newval.raw[idx] = *data;
+
+ asm volatile("// __lsui_user_swpb_asm\n"
+ __LSUI_PREAMBLE
+ "1: cast %x2, %x3, %1\n"
+ "2:\n"
+ _ASM_EXTABLE_UACCESS_ERR(1b, 2b, %w0)
+ : "+r" (err), "+Q" (*addr_al), "+r" (curval.var)
+ : "r" (newval.var)
+ : "memory");
+
+ if (curval.var == oldval) {
+ err = 0;
+ break;
+ }
+ }
+
+ if (!err)
+ *data = curval.raw[idx];
+
+ return err;
+}
+#endif /* CONFIG_AS_HAS_LSUI */
+
/*
* Error-checking SWP macros implemented using ldxr{b}/stxr{b}
*/
-/* Arbitrary constant to ensure forward-progress of the LL/SC loop */
-#define __SWP_LL_SC_LOOPS 4
-
#define LLSC_USER_SWPX(B) \
static __always_inline int \
__llsc_user_swp##B##_asm(unsigned int *data, unsigned int addr) \
@@ -117,7 +182,7 @@ __llsc_user_swp##B##_asm(unsigned int *data, unsigned int addr) \
_ASM_EXTABLE_UACCESS_ERR(1b, 3b, %w0) \
: "=&r" (err), "+r" (*data), "=&r" (temp), "=&r" (temp2)\
: "r" ((unsigned long)addr), "i" (-EAGAIN), \
- "i" (__SWP_LL_SC_LOOPS) \
+ "i" (__SWP_LOOPS) \
: "memory"); \
uaccess_disable_privileged(); \
\
@@ -128,9 +193,9 @@ LLSC_USER_SWPX()
LLSC_USER_SWPX(b)
#define __user_swp_asm(data, addr) \
- __llsc_user_swp_asm(data, addr)
+ __lsui_llsc_body(user_swp_asm, data, addr)
#define __user_swpb_asm(data, addr) \
- __llsc_user_swpb_asm(data, addr)
+ __lsui_llsc_body(user_swpb_asm, data, addr)
/*
* Bit 22 of the instruction encoding distinguishes between
--
LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}On Sun, 14 Dec 2025 11:22:48 +0000, Yeoreum Yun <yeoreum.yun@arm.com> wrote: > > Apply the FEAT_LSUI instruction to emulate the deprecated swpX > instruction, so that toggling of the PSTATE.PAN bit can be removed when > LSUI-related instructions are used. > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> It really begs the question: what are the odds of ever seeing a CPU that implements both LSUI and AArch32? This seems extremely unlikely to me. M. -- Without deviation from the norm, progress is not possible.
Hi, > On Sun, 14 Dec 2025 11:22:48 +0000, > Yeoreum Yun <yeoreum.yun@arm.com> wrote: > > > > Apply the FEAT_LSUI instruction to emulate the deprecated swpX > > instruction, so that toggling of the PSTATE.PAN bit can be removed when > > LSUI-related instructions are used. > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> > > It really begs the question: what are the odds of ever seeing a CPU > that implements both LSUI and AArch32? > > This seems extremely unlikely to me. Well, I'm not sure how many CPU will have both ID_AA64PFR0_EL1.EL0 bit as 0b0010 and FEAT_LSUI (except FVP currently) -- at least the CPU what I saw, most of them set ID_AA64PFR0_EL1.EL0 as 0b0010. If you this seems useless, I don't have any strong comments whether drop patches related to deprecated swp instruction parts (patch 8-9 only) or not. (But, I hope to pass this decision to maintaining perspective...) > > M. > > -- > Without deviation from the norm, progress is not possible. -- Sincerely, Yeoreum Yun
On Mon, Dec 15, 2025 at 09:56:04AM +0000, Yeoreum Yun wrote: > Hi, > > > On Sun, 14 Dec 2025 11:22:48 +0000, > > Yeoreum Yun <yeoreum.yun@arm.com> wrote: > > > > > > Apply the FEAT_LSUI instruction to emulate the deprecated swpX > > > instruction, so that toggling of the PSTATE.PAN bit can be removed when > > > LSUI-related instructions are used. > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> > > > > It really begs the question: what are the odds of ever seeing a CPU > > that implements both LSUI and AArch32? > > > > This seems extremely unlikely to me. > > Well, I'm not sure how many CPU will have > both ID_AA64PFR0_EL1.EL0 bit as 0b0010 and FEAT_LSUI > (except FVP currently) -- at least the CPU what I saw, > most of them set ID_AA64PFR0_EL1.EL0 as 0b0010. Just to make sure I understand you, you're saying that you have seen a real CPU that implements both 32-bit EL0 *and* FEAT_LSUI? > If you this seems useless, I don't have any strong comments > whether drop patches related to deprecated swp instruction parts > (patch 8-9 only) or not. > (But, I hope to pass this decision to maintaining perspective...) I think it depends on whether or not the hardware exists. Marc thinks that it's extremely unlikely whereas you appear to have seen some (but please confirm). Will
Hi Will, > On Mon, Dec 15, 2025 at 09:56:04AM +0000, Yeoreum Yun wrote: > > Hi, > > > > > On Sun, 14 Dec 2025 11:22:48 +0000, > > > Yeoreum Yun <yeoreum.yun@arm.com> wrote: > > > > > > > > Apply the FEAT_LSUI instruction to emulate the deprecated swpX > > > > instruction, so that toggling of the PSTATE.PAN bit can be removed when > > > > LSUI-related instructions are used. > > > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> > > > > > > It really begs the question: what are the odds of ever seeing a CPU > > > that implements both LSUI and AArch32? > > > > > > This seems extremely unlikely to me. > > > > Well, I'm not sure how many CPU will have > > both ID_AA64PFR0_EL1.EL0 bit as 0b0010 and FEAT_LSUI > > (except FVP currently) -- at least the CPU what I saw, > > most of them set ID_AA64PFR0_EL1.EL0 as 0b0010. > > Just to make sure I understand you, you're saying that you have seen > a real CPU that implements both 32-bit EL0 *and* FEAT_LSUI? > > > If you this seems useless, I don't have any strong comments > > whether drop patches related to deprecated swp instruction parts > > (patch 8-9 only) or not. > > (But, I hope to pass this decision to maintaining perspective...) > > I think it depends on whether or not the hardware exists. Marc thinks > that it's extremely unlikely whereas you appear to have seen some (but > please confirm). > What I meant was not a 32-bit CPU with LSUI, but a CPU that supports 32-bit EL0 compatibility (i.e. ID_AA64PFR0_EL1.EL0 = 0b0010). My point was that if CPUs implementing LSUI do appear, most of them will likely continue to support the existing 32-bit EL0 compatibility that the majority of current CPUs already have. For that reason, I think it also makes sense to apply LSUI to SWPx emulation. That said, since there are currently no real CPUs that actually implement LSUI, it is hard to say that this is particularly useful right now. I do not have a strong opinion on whether this patch should be applied or dropped at this point. Personally, given that most CPUs released so far support 32-bit compatibility, I expect that future CPUs with LSUI will also retain 32-bit compatibility. However, it is difficult to say with certainty which approach is correct at this time. I would therefore like to defer the final decision on this to the maintainers Am I missing something? -- Sincerely, Yeoreum Yun
On Mon, Jan 19, 2026 at 10:32:11PM +0000, Yeoreum Yun wrote: > > On Mon, Dec 15, 2025 at 09:56:04AM +0000, Yeoreum Yun wrote: > > > > On Sun, 14 Dec 2025 11:22:48 +0000, > > > > Yeoreum Yun <yeoreum.yun@arm.com> wrote: > > > > > > > > > > Apply the FEAT_LSUI instruction to emulate the deprecated swpX > > > > > instruction, so that toggling of the PSTATE.PAN bit can be removed when > > > > > LSUI-related instructions are used. > > > > > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> > > > > > > > > It really begs the question: what are the odds of ever seeing a CPU > > > > that implements both LSUI and AArch32? > > > > > > > > This seems extremely unlikely to me. > > > > > > Well, I'm not sure how many CPU will have > > > both ID_AA64PFR0_EL1.EL0 bit as 0b0010 and FEAT_LSUI > > > (except FVP currently) -- at least the CPU what I saw, > > > most of them set ID_AA64PFR0_EL1.EL0 as 0b0010. > > > > Just to make sure I understand you, you're saying that you have seen > > a real CPU that implements both 32-bit EL0 *and* FEAT_LSUI? > > > > > If you this seems useless, I don't have any strong comments > > > whether drop patches related to deprecated swp instruction parts > > > (patch 8-9 only) or not. > > > (But, I hope to pass this decision to maintaining perspective...) > > > > I think it depends on whether or not the hardware exists. Marc thinks > > that it's extremely unlikely whereas you appear to have seen some (but > > please confirm). > > What I meant was not a 32-bit CPU with LSUI, but a CPU that supports > 32-bit EL0 compatibility (i.e. ID_AA64PFR0_EL1.EL0 = 0b0010). > My point was that if CPUs implementing LSUI do appear, most of them will likely > continue to support the existing 32-bit EL0 compatibility that > the majority of current CPUs already have. That doesn't really answer Will's question. Will asked: Just to make sure I understand you, you're saying that you have seen a real CPU that implements both 32-bit EL0 *and* FEAT_LSUI? IIUC you have NOT seen any specific real CPU that supports this, and you have been testing on an FVP AEM model (which can be configured to support this combination of features). Can you please confirm? I don't beleive it's likely that we'll see hardware that supports both FEAT_LSUI and AArch32 (at EL0). Mark.
Hi Mark, > On Mon, Jan 19, 2026 at 10:32:11PM +0000, Yeoreum Yun wrote: > > > On Mon, Dec 15, 2025 at 09:56:04AM +0000, Yeoreum Yun wrote: > > > > > On Sun, 14 Dec 2025 11:22:48 +0000, > > > > > Yeoreum Yun <yeoreum.yun@arm.com> wrote: > > > > > > > > > > > > Apply the FEAT_LSUI instruction to emulate the deprecated swpX > > > > > > instruction, so that toggling of the PSTATE.PAN bit can be removed when > > > > > > LSUI-related instructions are used. > > > > > > > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> > > > > > > > > > > It really begs the question: what are the odds of ever seeing a CPU > > > > > that implements both LSUI and AArch32? > > > > > > > > > > This seems extremely unlikely to me. > > > > > > > > Well, I'm not sure how many CPU will have > > > > both ID_AA64PFR0_EL1.EL0 bit as 0b0010 and FEAT_LSUI > > > > (except FVP currently) -- at least the CPU what I saw, > > > > most of them set ID_AA64PFR0_EL1.EL0 as 0b0010. > > > > > > Just to make sure I understand you, you're saying that you have seen > > > a real CPU that implements both 32-bit EL0 *and* FEAT_LSUI? > > > > > > > If you this seems useless, I don't have any strong comments > > > > whether drop patches related to deprecated swp instruction parts > > > > (patch 8-9 only) or not. > > > > (But, I hope to pass this decision to maintaining perspective...) > > > > > > I think it depends on whether or not the hardware exists. Marc thinks > > > that it's extremely unlikely whereas you appear to have seen some (but > > > please confirm). > > > > What I meant was not a 32-bit CPU with LSUI, but a CPU that supports > > 32-bit EL0 compatibility (i.e. ID_AA64PFR0_EL1.EL0 = 0b0010). > > My point was that if CPUs implementing LSUI do appear, most of them will likely > > continue to support the existing 32-bit EL0 compatibility that > > the majority of current CPUs already have. > > That doesn't really answer Will's question. Will asked: > > Just to make sure I understand you, you're saying that you have seen a > real CPU that implements both 32-bit EL0 *and* FEAT_LSUI? > > IIUC you have NOT seen any specific real CPU that supports this, and you > have been testing on an FVP AEM model (which can be configured to > support this combination of features). Can you please confirm? > > I don't beleive it's likely that we'll see hardware that supports > both FEAT_LSUI and AArch32 (at EL0). Yes. I've tested in FVP model. and the latest of my reply said I confirmed that Marc's and your view was right. Thanks. -- Sincerely, Yeoreum Yun
On Tue, Jan 20, 2026 at 10:07:33AM +0000, Yeoreum Yun wrote: > Hi Mark, > > > On Mon, Jan 19, 2026 at 10:32:11PM +0000, Yeoreum Yun wrote: > > > > On Mon, Dec 15, 2025 at 09:56:04AM +0000, Yeoreum Yun wrote: > > > > > > On Sun, 14 Dec 2025 11:22:48 +0000, > > > > > > Yeoreum Yun <yeoreum.yun@arm.com> wrote: > > > > > > > > > > > > > > Apply the FEAT_LSUI instruction to emulate the deprecated swpX > > > > > > > instruction, so that toggling of the PSTATE.PAN bit can be removed when > > > > > > > LSUI-related instructions are used. > > > > > > > > > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> > > > > > > > > > > > > It really begs the question: what are the odds of ever seeing a CPU > > > > > > that implements both LSUI and AArch32? > > > > > > > > > > > > This seems extremely unlikely to me. > > > > > > > > > > Well, I'm not sure how many CPU will have > > > > > both ID_AA64PFR0_EL1.EL0 bit as 0b0010 and FEAT_LSUI > > > > > (except FVP currently) -- at least the CPU what I saw, > > > > > most of them set ID_AA64PFR0_EL1.EL0 as 0b0010. > > > > > > > > Just to make sure I understand you, you're saying that you have seen > > > > a real CPU that implements both 32-bit EL0 *and* FEAT_LSUI? > > > > > > > > > If you this seems useless, I don't have any strong comments > > > > > whether drop patches related to deprecated swp instruction parts > > > > > (patch 8-9 only) or not. > > > > > (But, I hope to pass this decision to maintaining perspective...) > > > > > > > > I think it depends on whether or not the hardware exists. Marc thinks > > > > that it's extremely unlikely whereas you appear to have seen some (but > > > > please confirm). > > > > > > What I meant was not a 32-bit CPU with LSUI, but a CPU that supports > > > 32-bit EL0 compatibility (i.e. ID_AA64PFR0_EL1.EL0 = 0b0010). > > > My point was that if CPUs implementing LSUI do appear, most of them will likely > > > continue to support the existing 32-bit EL0 compatibility that > > > the majority of current CPUs already have. > > > > That doesn't really answer Will's question. Will asked: > > > > Just to make sure I understand you, you're saying that you have seen a > > real CPU that implements both 32-bit EL0 *and* FEAT_LSUI? > > > > IIUC you have NOT seen any specific real CPU that supports this, and you > > have been testing on an FVP AEM model (which can be configured to > > support this combination of features). Can you please confirm? > > > > I don't beleive it's likely that we'll see hardware that supports > > both FEAT_LSUI and AArch32 (at EL0). > > Yes. I've tested in FVP model. and the latest of my reply said > I confirmed that Marc's and your view was right. It's probably still worth adding something to the cpufeature stuff to WARN() if we spot both LSUI and support for AArch32. Will
> On Tue, Jan 20, 2026 at 10:07:33AM +0000, Yeoreum Yun wrote: > > Hi Mark, > > > > > On Mon, Jan 19, 2026 at 10:32:11PM +0000, Yeoreum Yun wrote: > > > > > On Mon, Dec 15, 2025 at 09:56:04AM +0000, Yeoreum Yun wrote: > > > > > > > On Sun, 14 Dec 2025 11:22:48 +0000, > > > > > > > Yeoreum Yun <yeoreum.yun@arm.com> wrote: > > > > > > > > > > > > > > > > Apply the FEAT_LSUI instruction to emulate the deprecated swpX > > > > > > > > instruction, so that toggling of the PSTATE.PAN bit can be removed when > > > > > > > > LSUI-related instructions are used. > > > > > > > > > > > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> > > > > > > > > > > > > > > It really begs the question: what are the odds of ever seeing a CPU > > > > > > > that implements both LSUI and AArch32? > > > > > > > > > > > > > > This seems extremely unlikely to me. > > > > > > > > > > > > Well, I'm not sure how many CPU will have > > > > > > both ID_AA64PFR0_EL1.EL0 bit as 0b0010 and FEAT_LSUI > > > > > > (except FVP currently) -- at least the CPU what I saw, > > > > > > most of them set ID_AA64PFR0_EL1.EL0 as 0b0010. > > > > > > > > > > Just to make sure I understand you, you're saying that you have seen > > > > > a real CPU that implements both 32-bit EL0 *and* FEAT_LSUI? > > > > > > > > > > > If you this seems useless, I don't have any strong comments > > > > > > whether drop patches related to deprecated swp instruction parts > > > > > > (patch 8-9 only) or not. > > > > > > (But, I hope to pass this decision to maintaining perspective...) > > > > > > > > > > I think it depends on whether or not the hardware exists. Marc thinks > > > > > that it's extremely unlikely whereas you appear to have seen some (but > > > > > please confirm). > > > > > > > > What I meant was not a 32-bit CPU with LSUI, but a CPU that supports > > > > 32-bit EL0 compatibility (i.e. ID_AA64PFR0_EL1.EL0 = 0b0010). > > > > My point was that if CPUs implementing LSUI do appear, most of them will likely > > > > continue to support the existing 32-bit EL0 compatibility that > > > > the majority of current CPUs already have. > > > > > > That doesn't really answer Will's question. Will asked: > > > > > > Just to make sure I understand you, you're saying that you have seen a > > > real CPU that implements both 32-bit EL0 *and* FEAT_LSUI? > > > > > > IIUC you have NOT seen any specific real CPU that supports this, and you > > > have been testing on an FVP AEM model (which can be configured to > > > support this combination of features). Can you please confirm? > > > > > > I don't beleive it's likely that we'll see hardware that supports > > > both FEAT_LSUI and AArch32 (at EL0). > > > > Yes. I've tested in FVP model. and the latest of my reply said > > I confirmed that Marc's and your view was right. > > It's probably still worth adding something to the cpufeature stuff to > WARN() if we spot both LSUI and support for AArch32. > 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). Given that, I'm not sure a WARN is really necessary. Would it be sufficient to just drop the patch for swpX instead? Thanks! -- Sincerely, Yeoreum Yun
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. Will
> 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. Thanks! -- Sincerely, Yeoreum Yun
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? Will
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. -- Sincerely, Yeoreum Yun
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. Will
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
> On Tue, Jan 20, 2026 at 10:07:33AM +0000, Yeoreum Yun wrote: > > Hi Mark, > > > > > On Mon, Jan 19, 2026 at 10:32:11PM +0000, Yeoreum Yun wrote: > > > > > On Mon, Dec 15, 2025 at 09:56:04AM +0000, Yeoreum Yun wrote: > > > > > > > On Sun, 14 Dec 2025 11:22:48 +0000, > > > > > > > Yeoreum Yun <yeoreum.yun@arm.com> wrote: > > > > > > > > > > > > > > > > Apply the FEAT_LSUI instruction to emulate the deprecated swpX > > > > > > > > instruction, so that toggling of the PSTATE.PAN bit can be removed when > > > > > > > > LSUI-related instructions are used. > > > > > > > > > > > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> > > > > > > > > > > > > > > It really begs the question: what are the odds of ever seeing a CPU > > > > > > > that implements both LSUI and AArch32? > > > > > > > > > > > > > > This seems extremely unlikely to me. > > > > > > > > > > > > Well, I'm not sure how many CPU will have > > > > > > both ID_AA64PFR0_EL1.EL0 bit as 0b0010 and FEAT_LSUI > > > > > > (except FVP currently) -- at least the CPU what I saw, > > > > > > most of them set ID_AA64PFR0_EL1.EL0 as 0b0010. > > > > > > > > > > Just to make sure I understand you, you're saying that you have seen > > > > > a real CPU that implements both 32-bit EL0 *and* FEAT_LSUI? > > > > > > > > > > > If you this seems useless, I don't have any strong comments > > > > > > whether drop patches related to deprecated swp instruction parts > > > > > > (patch 8-9 only) or not. > > > > > > (But, I hope to pass this decision to maintaining perspective...) > > > > > > > > > > I think it depends on whether or not the hardware exists. Marc thinks > > > > > that it's extremely unlikely whereas you appear to have seen some (but > > > > > please confirm). > > > > > > > > What I meant was not a 32-bit CPU with LSUI, but a CPU that supports > > > > 32-bit EL0 compatibility (i.e. ID_AA64PFR0_EL1.EL0 = 0b0010). > > > > My point was that if CPUs implementing LSUI do appear, most of them will likely > > > > continue to support the existing 32-bit EL0 compatibility that > > > > the majority of current CPUs already have. > > > > > > That doesn't really answer Will's question. Will asked: > > > > > > Just to make sure I understand you, you're saying that you have seen a > > > real CPU that implements both 32-bit EL0 *and* FEAT_LSUI? > > > > > > IIUC you have NOT seen any specific real CPU that supports this, and you > > > have been testing on an FVP AEM model (which can be configured to > > > support this combination of features). Can you please confirm? > > > > > > I don't beleive it's likely that we'll see hardware that supports > > > both FEAT_LSUI and AArch32 (at EL0). > > > > Yes. I've tested in FVP model. and the latest of my reply said > > I confirmed that Marc's and your view was right. > > It's probably still worth adding something to the cpufeature stuff to > WARN() if we spot both LSUI and support for AArch32. > > Will If adding some check on cpufeature stuff for this, I think it also good to include the check PAN as you mentioned in another thread then. -- Sincerely, Yeoreum Yun
Hi, > Hi Will, > > > On Mon, Dec 15, 2025 at 09:56:04AM +0000, Yeoreum Yun wrote: > > > Hi, > > > > > > > On Sun, 14 Dec 2025 11:22:48 +0000, > > > > Yeoreum Yun <yeoreum.yun@arm.com> wrote: > > > > > > > > > > Apply the FEAT_LSUI instruction to emulate the deprecated swpX > > > > > instruction, so that toggling of the PSTATE.PAN bit can be removed when > > > > > LSUI-related instructions are used. > > > > > > > > > > Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> > > > > > > > > It really begs the question: what are the odds of ever seeing a CPU > > > > that implements both LSUI and AArch32? > > > > > > > > This seems extremely unlikely to me. > > > > > > Well, I'm not sure how many CPU will have > > > both ID_AA64PFR0_EL1.EL0 bit as 0b0010 and FEAT_LSUI > > > (except FVP currently) -- at least the CPU what I saw, > > > most of them set ID_AA64PFR0_EL1.EL0 as 0b0010. > > > > Just to make sure I understand you, you're saying that you have seen > > a real CPU that implements both 32-bit EL0 *and* FEAT_LSUI? > > > > > If you this seems useless, I don't have any strong comments > > > whether drop patches related to deprecated swp instruction parts > > > (patch 8-9 only) or not. > > > (But, I hope to pass this decision to maintaining perspective...) > > > > I think it depends on whether or not the hardware exists. Marc thinks > > that it's extremely unlikely whereas you appear to have seen some (but > > please confirm). > > > > What I meant was not a 32-bit CPU with LSUI, but a CPU that supports > 32-bit EL0 compatibility (i.e. ID_AA64PFR0_EL1.EL0 = 0b0010). > My point was that if CPUs implementing LSUI do appear, most of them will likely > continue to support the existing 32-bit EL0 compatibility that > the majority of current CPUs already have. > > For that reason, I think it also makes sense to apply LSUI to SWPx emulation. > That said, since there are currently no real CPUs that actually implement LSUI, > it is hard to say that this is particularly useful right now. > I do not have a strong opinion on whether this patch should be applied or > dropped at this point. > Personally, given that most CPUs released so far support 32-bit compatibility, > I expect that future CPUs with LSUI will also retain 32-bit compatibility. > However, it is difficult to say with certainty which approach > is correct at this time. > > I would therefore like to defer the final decision on this to the maintainers > > Am I missing something? Ah, the Marc view was right. So I think the changes for swpX could be droppable. Thanks. -- Sincerely, Yeoreum Yun
© 2016 - 2026 Red Hat, Inc.