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