cacheflush completely broken, suspecting PAN+LPAE
Michał Pecio
michal.pecio at gmail.com
Tue Nov 12 09:10:17 PST 2024
On Tue, 12 Nov 2024 10:21:36 +0000, Russell King (Oracle) wrote:
> From: "Russell King (Oracle)" <rmk+kernel at armlinux.org.uk>
> Subject: [PATCH] ARM: fix cacheflush with PAN
>
> It seems that the cacheflush syscall got broken when PAN was
> implemented. User access was not enabled around the cache maintenance
> instructions, causing them to fault.
>
> Fixes: a5e090acbf54 ("ARM: software-based priviledged-no-access support")
For the record, non-LPAE seems to be OK, so for me it was 7af5b901e847.
> Reported-by: From: Michał Pecio <michal.pecio at gmail.com>
"From:" perhaps not strictly necessary ;)
Tested-by: Michał Pecio <michal.pecio at gmail.com>
That was it. With this patch gdb starts normally, does 295 cacheflush
calls and all of them succeed, with ARM_LPAE and ARM_PAN enabled.
> Signed-off-by: Russell King (Oracle) <rmk+kernel at armlinux.org.uk>
> ---
> arch/arm/kernel/traps.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
> index 54dcdcde3f77..6518771c1496 100644
> --- a/arch/arm/kernel/traps.c
> +++ b/arch/arm/kernel/traps.c
> @@ -574,6 +574,7 @@ static int bad_syscall(int n, struct pt_regs *regs)
> static inline int
> __do_cache_op(unsigned long start, unsigned long end)
> {
> + unsigned int ua_flags;
> int ret;
>
> do {
> @@ -582,7 +583,9 @@ __do_cache_op(unsigned long start, unsigned long end)
> if (fatal_signal_pending(current))
> return 0;
>
> + ua_flags = uaccess_save_and_enable();
> ret = flush_icache_user_range(start, start + chunk);
> + uaccess_restore(ua_flags);
> if (ret)
> return ret;
>
> --
> 2.30.2
More information about the linux-arm-kernel
mailing list