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
| ||
|
Date: Wed, 29 Jul 2020 20:40:57 +0000 From: Fenghua Yu <fenghua.yu@...el.com> To: peterz@...radead.org Cc: Fenghua Yu <fenghua.yu@...el.com>, Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...hat.com>, Tony Luck <tony.luck@...el.com>, H Peter Anvin <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>, Ravi V Shankar <ravi.v.shankar@...el.com>, Xiaoyao Li <xiaoyao.li@...el.com>, x86 <x86@...nel.org>, linux-kernel <linux-kernel@...r.kernel.org> Subject: Re: [PATCH RFC] x86/bus_lock: Enable bus lock detection Hi, Peter, On Wed, Jul 29, 2020 at 10:49:47AM +0200, peterz@...radead.org wrote: > On Fri, Jul 17, 2020 at 02:35:00PM -0700, Fenghua Yu wrote: > > > #DB for bus lock detect fixes all issues in #AC for split lock detect: > > 1) It's architectural ... just need to look at one CPUID bit to know it > > exists > > 2) The IA32_DEBUGCTL MSR, which reports bus lock in #DB, is per-thread. > > So each process or guest can have different behavior. > > And it generates a whole new problem due to #DB being an IST, and > > > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c > > index b038695f36c5..58725567da39 100644 > > --- a/arch/x86/kernel/traps.c > > +++ b/arch/x86/kernel/traps.c > > @@ -812,6 +812,16 @@ static void handle_debug(struct pt_regs *regs, unsigned long dr6, bool user) > > if (!user && !dr6) > > return; > > > > + /* Handle bus lock. */ > > + if (!(dr6 & DR_BUS_LOCK)) { > > + cond_local_irq_enable(regs); > > + if (user) > > + handle_user_bus_lock(regs); > > + else > > + handle_kernel_bus_lock(regs); > > + goto out; > > + } > > + > > /* > > * If dr6 has no reason to give us about the origin of this trap, > > * then it's very likely the result of an icebp/int01 trap. > > we very much rely on #DB never recursing, which we carefully crafted by > disallowing hardare breakpoints on noinstr code and clearing DR7 early. > > But now it can... please keep the pieces. Can we disable Bus Lock Detection before handle it and re-enable it after handle it? Will that resolve the recursion issue? Thanks. -Fenghua
Powered by blists - more mailing lists