[PATCH 2/2] powerpc/64: Only warn for kuap locked when KCSAN not present

[Christophe Leroy]

Le 04/04/2024 à 06:45, Rohan McLure a écrit :
> Arbitrary instrumented locations, including syscall handlers, can call
> arch_local_irq_restore() transitively when KCSAN is enabled, and in turn
> also replay_soft_interrupts_irqrestore(). The precondition on entry to
> this routine that is checked is that KUAP is enabled (user access
> prohibited). Failure to meet this condition only triggers a warning
> however, and afterwards KUAP is enabled anyway. That is, KUAP being
> disabled on entry is in fact permissable, but not possible on an
> uninstrumented kernel.
> 
> Disable this assertion only when KCSAN is enabled.

Please elaborate on that arbitrary call to arch_local_irq_restore() 
transitively, when does it happen and why, and why only when KCSAN is 
enabled.

I don't understand the reasoning, if it is permissible as you say, just 
drop the warning. If the warning is there, it should stay also with 
KCSAN. You should fix the root cause instead.

> 
> Suggested-by: Nicholas Piggin <npiggin at gmail.com>
> Signed-off-by: Rohan McLure <rmclure at linux.ibm.com>
> ---
>   arch/powerpc/kernel/irq_64.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/kernel/irq_64.c b/arch/powerpc/kernel/irq_64.c
> index d5c48d1b0a31..18b2048389a2 100644
> --- a/arch/powerpc/kernel/irq_64.c
> +++ b/arch/powerpc/kernel/irq_64.c
> @@ -189,7 +189,8 @@ static inline __no_kcsan void replay_soft_interrupts_irqrestore(void)
>   	 * and re-locking AMR but we shouldn't get here in the first place,
>   	 * hence the warning.
>   	 */
> -	kuap_assert_locked();
> +	if (!IS_ENABLED(CONFIG_KCSAN))
> +		kuap_assert_locked();
>   
>   	if (kuap_state != AMR_KUAP_BLOCKED)
>   		set_kuap(AMR_KUAP_BLOCKED);