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: Thu, 4 Jul 2019 00:05:22 +0200 From: Peter Zijlstra <peterz@...radead.org> To: Steven Rostedt <rostedt@...dmis.org> Cc: Andy Lutomirski <luto@...nel.org>, Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...nel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, "H. Peter Anvin" <hpa@...or.com>, Dave Hansen <dave.hansen@...ux.intel.com>, Juergen Gross <jgross@...e.com>, LKML <linux-kernel@...r.kernel.org>, He Zhe <zhe.he@...driver.com>, Joel Fernandes <joel@...lfernandes.org>, devel@...ukata.com Subject: Re: [PATCH 3/3] x86/mm, tracing: Fix CR2 corruption On Wed, Jul 03, 2019 at 04:47:01PM -0400, Steven Rostedt wrote: > On Wed, 3 Jul 2019 13:27:09 -0700 > Andy Lutomirski <luto@...nel.org> wrote: > > > > > @@ -1180,10 +1189,10 @@ idtentry xenint3 do_int3 has_error_co > > > #endif > > > > > > idtentry general_protection do_general_protection has_error_code=1 > > > -idtentry page_fault do_page_fault has_error_code=1 > > > +idtentry page_fault do_page_fault has_error_code=1 read_cr2=1 > > > > > > #ifdef CONFIG_KVM_GUEST > > > -idtentry async_page_fault do_async_page_fault has_error_code=1 > > > +idtentry async_page_fault do_async_page_fault has_error_code=1 read_cr2=1 > > > #endif > > > > > > #ifdef CONFIG_X86_MCE > > > @@ -1338,18 +1347,9 @@ ENTRY(error_entry) > > > movq %rax, %rsp /* switch stack */ > > > ENCODE_FRAME_POINTER > > > pushq %r12 > > > - > > > - /* > > > - * We need to tell lockdep that IRQs are off. We can't do this until > > > - * we fix gsbase, and we should do it before enter_from_user_mode > > > - * (which can take locks). > > > - */ > > > - TRACE_IRQS_OFF > > > > This hunk looks wrong. Am I missing some other place that handles the > > case where we enter from kernel mode and IRQs were on? > > Yeah, looks like we might be missing a TRACE_IRQS_OFF from the > from_usermode_stack_switch path. Oh bugger, there's a second error_entry call.
Powered by blists - more mailing lists