linux-kernel - Re: [PATCH v4 7/9] kentry: Add debugging checks for proper kentry API usage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87pmzv5d90.fsf@nanos.tec.linutronix.de>
Date:   Fri, 19 Mar 2021 17:17:47 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andy Lutomirski <luto@...nel.org>, x86@...nel.org
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        Brian Gerst <brgerst@...il.com>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH v4 7/9] kentry: Add debugging checks for proper kentry API usage

On Wed, Mar 17 2021 at 11:12, Andy Lutomirski wrote:
> +
> +#define DEBUG_ENTRY_WARN_ONCE(condition, format...) do {} while (0)

So we have a stub for !DEBUG

> +static __always_inline void kentry_cpu_depth_add(unsigned int n) {}
> +static void kentry_cpu_depth_check(unsigned int n) {}
> +static __always_inline void kentry_cpu_depth_sub(unsigned int n) {}
> +
> +#endif
> +
>  /* See comment for enter_from_user_mode() in entry-common.h */
>  static __always_inline void __enter_from_user_mode(struct pt_regs *regs)
>  {
> +	kentry_cpu_depth_add(1);
>  	arch_check_user_regs(regs);
>  	lockdep_hardirqs_off(CALLER_ADDR0);
>  
> @@ -22,6 +78,14 @@ static __always_inline void __enter_from_user_mode(struct pt_regs *regs)
>  
>  	instrumentation_begin();
>  	trace_hardirqs_off_finish();
> +
> +#ifdef CONFIG_DEBUG_ENTRY

Why do we need that #ifdeffery all over the place?

> +	DEBUG_ENTRY_WARN_ONCE(
> +		this_cpu_read(kentry_cpu_depth) != 1,
> +		"kentry: __enter_from_user_mode() called while kentry thought the CPU was in the kernel (%u)",
> +		this_cpu_read(kentry_cpu_depth));

Thanks,

        tglx