This is the second attempt of the patch, reviewed as follows:
* Reworked subject and description to avoid the term 'emulation' and to
address generically 'exceptions' instead of 'syscalls' (mark.rutland)
* Moved aarch32_enabled() check inside system_supports_32bit_el0()
(mark.rutland)
* Renamed AARCH32_EMULATION_DEFAULT_DISABLED to AARCH32_SUPPORT_DEFAULT_DISABLED
(mark.rutland)
* Fixed a compilation Warning about missing function prototype
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
This is just for completeness since other possible solutions have been
proposed that could be better suited, see for example:
https://lkml.kernel.org/linux-fsdevel/[email protected]/
and followups. So, this patchset is just for reference, may be useful in the
future if some kind of exploit is found to bypass the 32bit process
enablement check (letting a process call 32bit syscalls) and nothing better
has been proposed meanwhile.
Andrea della Porta (4):
arm64: Introduce aarch32_enabled()
arm64/process: Make loading of 32bit processes depend on
aarch32_enabled()
arm64/entry-common: Make Aarch32 exceptions' availability depend on
aarch32_enabled()
arm64: Make Aarch32 support boot time configurable
.../admin-guide/kernel-parameters.txt | 7 ++++
arch/arm64/Kconfig | 9 +++++
arch/arm64/include/asm/cpufeature.h | 20 +++++++++--
arch/arm64/include/asm/exception.h | 7 ++++
arch/arm64/kernel/entry-common.c | 33 +++++++++++++++++--
5 files changed, 71 insertions(+), 5 deletions(-)
--
2.35.3
Major aspect of Aarch32 support is the ability to load 32bit
processes.
That's currently decided (among others) by compat_elf_check_arch()
and system_supports_32bit_el0().
Make the macro use aarch32_enabled() to decide if Aarch32 compat is
enabled before loading a 32bit process.
Signed-off-by: Andrea della Porta <[email protected]>
---
arch/arm64/include/asm/cpufeature.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 1180d68daaff..778f2f3b2c7d 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -679,8 +679,9 @@ static inline bool system_supports_32bit_el0(void)
{
u64 pfr0 = read_sanitised_ftr_reg(SYS_ID_AA64PFR0_EL1);
- return static_branch_unlikely(&arm64_mismatched_32bit_el0) ||
- id_aa64pfr0_32bit_el0(pfr0);
+ return (static_branch_unlikely(&arm64_mismatched_32bit_el0) ||
+ id_aa64pfr0_32bit_el0(pfr0)) &&
+ aarch32_enabled();
}
static inline bool system_supports_4kb_granule(void)
--
2.35.3
Aarch32 bit support on 64bit kernels depends on whether CONFIG_COMPAT
is selected or not. As it is a compile time option it doesn't
provide the flexibility to have distributions set their own policy for
Aarch32 support and give the user the flexibility to override it.
As a first step introduce aarch32_enabled() which abstracts whether 32
bit compat is turned on or off. Upcoming patches will implement
the ability to set Aarch32 compat state at boot time.
Signed-off-by: Andrea della Porta <[email protected]>
---
arch/arm64/include/asm/cpufeature.h | 15 +++++++++++++++
arch/arm64/kernel/entry-common.c | 2 ++
2 files changed, 17 insertions(+)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 396af9b9c857..1180d68daaff 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -657,6 +657,21 @@ static inline bool supports_clearbhb(int scope)
ID_AA64ISAR2_EL1_CLRBHB_SHIFT);
}
+#ifdef CONFIG_COMPAT
+extern bool __aarch32_enabled;
+
+static inline bool aarch32_enabled(void)
+{
+ return __aarch32_enabled;
+}
+#else /* !CONFIG_COMPAT */
+
+static inline bool aarch32_enabled(void)
+{
+ return false;
+}
+#endif
+
const struct cpumask *system_32bit_el0_cpumask(void);
DECLARE_STATIC_KEY_FALSE(arm64_mismatched_32bit_el0);
diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index 0fc94207e69a..69ff9b8c0bde 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -877,6 +877,8 @@ asmlinkage void noinstr el0t_32_error_handler(struct pt_regs *regs)
{
__el0_error_handler_common(regs);
}
+
+bool __aarch32_enabled __ro_after_init = true;
#else /* CONFIG_COMPAT */
UNHANDLED(el0t, 32, sync)
UNHANDLED(el0t, 32, irq)
--
2.35.3
Distributions would like to reduce their attack surface as much as
possible but at the same time they'd want to retain flexibility to
cater to a variety of legacy software. This stems from the conjecture
that compat layer is likely rarely tested and could have latent
security bugs. Ideally distributions will set their default policy
and also give users the ability to override it as appropriate.
To enable this use case, introduce CONFIG_AARCH32_SUPPORT_DEFAULT_DISABLED
compile time option, which controls whether 32bit processes/exceptions
should be allowed or not. This option is aimed mainly at distributions
to set their preferred default behavior in their kernels.
To allow users to override the distro's policy, introduce the
'allow_32bit_el0' parameter which allows overriding
CONFIG_AARCH32_SUPPORT_DEFAULT_DISABLED state at boot time.
Signed-off-by: Andrea della Porta <[email protected]>
---
Documentation/admin-guide/kernel-parameters.txt | 7 +++++++
arch/arm64/Kconfig | 9 +++++++++
arch/arm64/kernel/entry-common.c | 8 +++++++-
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 0a1731a0f0ef..9752c4640bd7 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1,3 +1,10 @@
+ allow_32bit_el0= [ARM64]
+ Format: <bool>
+ When true, allows loading 32-bit programs and executing
+ 32-bit syscalls and exceptions, essentially overriding
+ AARCH32_SUPPORT_DEFAULT_DISABLED at boot time. when false,
+ unconditionally disables AARCH32 support.
+
acpi= [HW,ACPI,X86,ARM64,RISCV64]
Advanced Configuration and Power Interface
Format: { force | on | off | strict | noirq | rsdt |
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b10515c0200b..c8e1b3535018 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1725,6 +1725,15 @@ config SETEND_EMULATION
If unsure, say Y
endif # ARMV8_DEPRECATED
+config AARCH32_SUPPORT_DEFAULT_DISABLED
+ bool "Aarch32 support disabled by default"
+ default n
+ depends on COMPAT
+ help
+ Make Aarch32 support disabled by default. This prevents loading 32-bit
+ processes and access to 32-bit syscalls and exceptions.
+
+ If unsure, leave it to its default value.
endif # COMPAT
menu "ARMv8.1 architectural features"
diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index 32761760d9dd..7698057ef4ce 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -897,7 +897,13 @@ asmlinkage void noinstr el0t_32_error_handler(struct pt_regs *regs)
__el0_error_handler_common(regs);
}
-bool __aarch32_enabled __ro_after_init = true;
+bool __aarch32_enabled __ro_after_init = !IS_ENABLED(CONFIG_AARCH32_SUPPORT_DEFAULT_DISABLED);
+
+static int aarch32_support_override_cmdline(char *arg)
+{
+ return kstrtobool(arg, &__aarch32_enabled);
+}
+early_param("allow_32bit_el0", aarch32_support_override_cmdline);
#else /* CONFIG_COMPAT */
UNHANDLED(el0t, 32, sync)
UNHANDLED(el0t, 32, irq)
--
2.35.3
On 23/10/2023 3:42 pm, Andrea della Porta wrote:
> Aarch32 bit support on 64bit kernels depends on whether CONFIG_COMPAT
> is selected or not. As it is a compile time option it doesn't
> provide the flexibility to have distributions set their own policy for
> Aarch32 support and give the user the flexibility to override it.
>
> As a first step introduce aarch32_enabled() which abstracts whether 32
> bit compat is turned on or off. Upcoming patches will implement
> the ability to set Aarch32 compat state at boot time.
Other than patch #3, which as previously mentioned should be unnecessary
if the kernel correctly never starts an "unsupported" AArch32 process to
begin with, what does this do that simply overriding ID_AA64PFR0_EL1.EL0
via the existing idreg-override mechanism wouldn't?
Thanks,
Robin.
> Signed-off-by: Andrea della Porta <[email protected]>
> ---
> arch/arm64/include/asm/cpufeature.h | 15 +++++++++++++++
> arch/arm64/kernel/entry-common.c | 2 ++
> 2 files changed, 17 insertions(+)
>
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index 396af9b9c857..1180d68daaff 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -657,6 +657,21 @@ static inline bool supports_clearbhb(int scope)
> ID_AA64ISAR2_EL1_CLRBHB_SHIFT);
> }
>
> +#ifdef CONFIG_COMPAT
> +extern bool __aarch32_enabled;
> +
> +static inline bool aarch32_enabled(void)
> +{
> + return __aarch32_enabled;
> +}
> +#else /* !CONFIG_COMPAT */
> +
> +static inline bool aarch32_enabled(void)
> +{
> + return false;
> +}
> +#endif
> +
> const struct cpumask *system_32bit_el0_cpumask(void);
> DECLARE_STATIC_KEY_FALSE(arm64_mismatched_32bit_el0);
>
> diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
> index 0fc94207e69a..69ff9b8c0bde 100644
> --- a/arch/arm64/kernel/entry-common.c
> +++ b/arch/arm64/kernel/entry-common.c
> @@ -877,6 +877,8 @@ asmlinkage void noinstr el0t_32_error_handler(struct pt_regs *regs)
> {
> __el0_error_handler_common(regs);
> }
> +
> +bool __aarch32_enabled __ro_after_init = true;
> #else /* CONFIG_COMPAT */
> UNHANDLED(el0t, 32, sync)
> UNHANDLED(el0t, 32, irq)
On 12:56 Tue 24 Oct , Robin Murphy wrote:
> On 23/10/2023 3:42 pm, Andrea della Porta wrote:
> > Aarch32 bit support on 64bit kernels depends on whether CONFIG_COMPAT
> > is selected or not. As it is a compile time option it doesn't
> > provide the flexibility to have distributions set their own policy for
> > Aarch32 support and give the user the flexibility to override it.
> >
> > As a first step introduce aarch32_enabled() which abstracts whether 32
> > bit compat is turned on or off. Upcoming patches will implement
> > the ability to set Aarch32 compat state at boot time.
>
> Other than patch #3, which as previously mentioned should be unnecessary if
> the kernel correctly never starts an "unsupported" AArch32 process to begin
> with, what does this do that simply overriding ID_AA64PFR0_EL1.EL0 via the
> existing idreg-override mechanism wouldn't?
>
> Thanks,
> Robin
You're right, I guess we can simpluy leverage system_supports_32bit_el0()
calling id_aa64pfr0_32bit_el0() and override the el0 nibble from command line,
instead of inventing a new kernel parameter. For the sake of simplicity,
maybe we can add a new alias in idreg-override, something like 'arm64.no32bit-el0'.
Thanks,
Andrea