From: Peter Zijlstra <peterz@infradead.org>
To: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
Lai Jiangshan <laijs@linux.alibaba.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 1/3] X86/db: Change __this_cpu_read() to this_cpu_read() in hw_breakpoint_active()
Date: Mon, 13 Dec 2021 20:46:24 +0100 [thread overview]
Message-ID: <20211213194624.GZ16608@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20211213042215.3096-2-jiangshanlai@gmail.com>
On Mon, Dec 13, 2021 at 12:22:13PM +0800, Lai Jiangshan wrote:
> From: Lai Jiangshan <laijs@linux.alibaba.com>
>
> __this_cpu_read() can not be instrumented except its own debugging code
> when CONFIG_DEBUG_PREEMPT. The debugging code will call
> __this_cpu_preempt_check(). __this_cpu_preempt_check() itself is also
> noinstr, so __this_cpu_read() can be used in noinstr.
>
> But these is one exception when exc_debug_kernel() calls local_db_save()
> which calls hw_breakpoint_active() which calls __this_cpu_read(). If
> the data accessed by __this_cpu_preempt_check() is also watched by
> hw_breakpoints, it would cause recursive #DB.
>
> this_cpu_read() in X86 is also non instrumentable, and it doesn't access
> to any extra data except the percpu cpu_dr7, and cpu_dr7 is disallowed
> to be watched in arch_build_bp_info(). So this_cpu_read() is safe to
> be used when hw_breakpoints is still active, and __this_cpu_read() here
> should be changed to this_cpu_read().
>
> This problem can only happen when the system owner uses a kernel with
> CONFIG_DEBUG_PREEMPT enabled and deliberately use hw_breakpoints on
> the data that __this_cpu_preempt_check() accesses. Sot it is just a
> problem with no significance.
>
> One might suggest that, all the data accessed by noinstr functions
> should be marked in denylist for hw_breakpoints. That would complexify
> the noinstrment framework and add hurdles to anyone that who want to
> add a new noinstr function. All we need is to suppress #DB in the IST
> interrupt entry path until safe place where #DB is disabled in hardware
> or #DB handler can handle well even it hits data accessed by noinstr
> function. Changing __this_cpu_read() to this_cpu_read() is fit for it.
>
> Signed-off-by: Lai Jiangshan <laijs@linux.alibaba.com>
> ---
> arch/x86/include/asm/debugreg.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/include/asm/debugreg.h b/arch/x86/include/asm/debugreg.h
> index cfdf307ddc01..20189ce41578 100644
> --- a/arch/x86/include/asm/debugreg.h
> +++ b/arch/x86/include/asm/debugreg.h
> @@ -87,7 +87,7 @@ static inline void hw_breakpoint_disable(void)
>
> static __always_inline bool hw_breakpoint_active(void)
> {
> - return __this_cpu_read(cpu_dr7) & DR_GLOBAL_ENABLE_MASK;
> + return this_cpu_read(cpu_dr7) & DR_GLOBAL_ENABLE_MASK;
I don't really follow the argument for why this_cpu_read(); why not
raw_cpu_read() instead, which is what __this_cpu_read() is based on.
Also, this really needs a comment.
Alternatively, we should remove noinstr from check_preemption_disabled()
and fix up all the fallout, but that seems like far more work than it's
worth.
/*
* Must not hit a breakpoint in check_preempt_disabled()
*/
return raw_cpu_read(cpu_dr7) & DR_GLOBAL_ENABLE_MASK;
> }
>
> extern void hw_breakpoint_restore(void);
> --
> 2.19.1.6.gb485710b
>
next prev parent reply other threads:[~2021-12-13 19:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-13 4:22 [PATCH 0/3] x86/entry: Fix 3 suspicious bugs Lai Jiangshan
2021-12-13 4:22 ` [PATCH 1/3] X86/db: Change __this_cpu_read() to this_cpu_read() in hw_breakpoint_active() Lai Jiangshan
2021-12-13 19:09 ` Borislav Petkov
2021-12-14 2:51 ` Lai Jiangshan
2021-12-14 9:33 ` Borislav Petkov
2021-12-13 19:46 ` Peter Zijlstra [this message]
2021-12-13 4:22 ` [PATCH 2/3] x86/hw_breakpoint: Add stack_canary to hw_breakpoints denylist Lai Jiangshan
2021-12-13 19:57 ` Peter Zijlstra
2021-12-13 4:22 ` [PATCH 3/3] x86/sev: The code for returning to user space is also in syscall gap Lai Jiangshan
2021-12-14 21:51 ` Borislav Petkov
2021-12-17 10:05 ` Joerg Roedel
2021-12-17 10:30 ` Borislav Petkov
2021-12-17 11:00 ` Joerg Roedel
2022-01-18 10:32 ` Borislav Petkov
2022-01-18 15:37 ` Lai Jiangshan
2022-04-12 13:00 ` Lai Jiangshan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211213194624.GZ16608@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jiangshanlai@gmail.com \
--cc=laijs@linux.alibaba.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.