Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-18 Thread Borislav Petkov
On Thu, Nov 17, 2016 at 03:33:21PM -0800, Andy Lutomirski wrote: > Huh, go figure. How about access_ok() instead? There's also > pagefault_disable() + copy_from_user(). Ah, you don't want to have another #PF during the first one. How about copy_from_user_nmi()? It already does __range_not_ok()

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-17 Thread Andy Lutomirski
On Nov 13, 2016 10:18 PM, "Borislav Petkov" wrote: > > On Sun, Nov 13, 2016 at 08:15:01AM -0800, Andy Lutomirski wrote: > > How about dropping the __ in front of the copy? > > In front of __copy_from_user_inatomic()? > > If so, is there even a global helper by that name? > > $ git grep -E "[^_]cop

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-15 Thread Ingo Molnar
* Borislav Petkov wrote: > On Tue, Nov 15, 2016 at 11:19:03AM +0100, Ingo Molnar wrote: > > Well, bfd8d3f23b51 was part of -rc1 already, so you have it too. > > Right. > > > What might have made the difference is that I tested it on real hardware > > with > > serial logging, which delays pri

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-15 Thread Borislav Petkov
On Tue, Nov 15, 2016 at 11:19:03AM +0100, Ingo Molnar wrote: > Well, bfd8d3f23b51 was part of -rc1 already, so you have it too. Right. > What might have made the difference is that I tested it on real hardware with > serial logging, which delays printk() and might have created the race with > t

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-15 Thread Ingo Molnar
* Borislav Petkov wrote: > On Tue, Nov 15, 2016 at 07:14:47AM +0100, Ingo Molnar wrote: > > So I think the line breaking artifact might be due to the following commit: > > > > bfd8d3f23b51 ("printk: make reading the kernel log flush pending lines") > > > > ... which Linus reverted upstream a

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-15 Thread Borislav Petkov
On Tue, Nov 15, 2016 at 07:14:47AM +0100, Ingo Molnar wrote: > So I think the line breaking artifact might be due to the following commit: > > bfd8d3f23b51 ("printk: make reading the kernel log flush pending lines") > > ... which Linus reverted upstream a few hours ago: Probably. I guess this

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-14 Thread Ingo Molnar
* Borislav Petkov wrote: > On Sun, Nov 13, 2016 at 12:25:52PM +0100, Borislav Petkov wrote: > > Hmm, enabling all *PRINTK* options from your .config doesn't change > > anything for my qemu guest here. Lemme try with your full config. > > Same with your .config: > > [ 115.694717] strsep[3027]:

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-13 Thread Borislav Petkov
On Sun, Nov 13, 2016 at 08:15:01AM -0800, Andy Lutomirski wrote: > How about dropping the __ in front of the copy? In front of __copy_from_user_inatomic()? If so, is there even a global helper by that name? $ git grep -E "[^_]copy_from_user_inatomic" drivers/gpu/drm/msm/msm_gem_submit.c:98:

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-13 Thread Andy Lutomirski
On Nov 12, 2016 4:27 AM, "Borislav Petkov" wrote: > > On Sat, Nov 12, 2016 at 12:06:49PM +0100, Ingo Molnar wrote: > > Note that on recent kernels, with printk log timestamping enabled, this > > looks > > like: > > > > [ 206.721243] CR2: CR3: 00042ab75000 CR4: > > 0

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-13 Thread Borislav Petkov
On Sun, Nov 13, 2016 at 12:25:52PM +0100, Borislav Petkov wrote: > Hmm, enabling all *PRINTK* options from your .config doesn't change > anything for my qemu guest here. Lemme try with your full config. Same with your .config: [ 115.694717] strsep[3027]: segfault at 40066b ip 77abe22b sp

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-13 Thread Borislav Petkov
On Sun, Nov 13, 2016 at 08:39:03AM +0100, Ingo Molnar wrote: > That's definitely how it came out of 'dmesg' - I've attached my .config. Hmm, enabling all *PRINTK* options from your .config doesn't change anything for my qemu guest here. Lemme try with your full config. > That runtime flag is defi

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-12 Thread Ingo Molnar
* Borislav Petkov wrote: > On Sat, Nov 12, 2016 at 12:06:49PM +0100, Ingo Molnar wrote: > > Note that on recent kernels, with printk log timestamping enabled, this > > looks > > like: > > > > [ 206.721243] CR2: CR3: 00042ab75000 CR4: > > 001406e0 > > [ 206.7292

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-12 Thread Borislav Petkov
On Sat, Nov 12, 2016 at 12:06:49PM +0100, Ingo Molnar wrote: > Note that on recent kernels, with printk log timestamping enabled, this looks > like: > > [ 206.721243] CR2: CR3: 00042ab75000 CR4: > 001406e0 > [ 206.729217] Code: > [ 206.731271] 55 > [ 206.733046

Re: [RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-12 Thread Ingo Molnar
* Borislav Petkov wrote: > From: Borislav Petkov > > I found out recently that this is very helpful when trying to look at > opcodes around the rIP when the segfault happens, and also poke at > architectural registers. When enabled, it looks something like this: > > strsep[3702]: segfault a

[RFC PATCH] x86/debug: Dump more detailed segfault info

2016-11-11 Thread Borislav Petkov
From: Borislav Petkov I found out recently that this is very helpful when trying to look at opcodes around the rIP when the segfault happens, and also poke at architectural registers. When enabled, it looks something like this: strsep[3702]: segfault at 40066b ip 77abe22b sp 7f