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

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: <20161113073903.GA648@gmail.com>
Date:   Sun, 13 Nov 2016 08:39:03 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC PATCH] x86/debug: Dump more detailed segfault info


* Borislav Petkov <bp@...en8.de> 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: 0000000000000000 CR3: 000000042ab75000 CR4: 00000000001406e0
> > [  206.729217] Code: 
> > [  206.731271] 55 
> > [  206.733046] 48 
> > [  206.733348] 89 
> > [  206.733665] e5 
> > [  206.733982] ff 
> 
> Hmm, this would then be no different with the "normal" Code: line as
> I simply stole it from there. And I have CONFIG_PRINTK_TIME=y. And it
> looks ok in my guest:

That's definitely how it came out of 'dmesg' - I've attached my .config.

> > So I don't mind the feature, but this should only dump code that is user-readable.
> 
> Yeah, this is purely a debug feature so how about I stick it behind a
> switch in debugfs which is root-only and it is disabled by default? When
> you boot, you do:
> 
> # echo 1 > /sys/kernel/debug/x86/detailed_segfault
> 
> Hmmm?

That runtime flag is definitely useful, but I think we should also do the proper 
permission checks - for 'defense in depth' reasons and all that.

There might be situations where an admin might want to use this on a production 
system - I had some trouble in the past getting/seeing segfaults that trigger in 
SystemD for example.

Thanks,

	Ingo

View attachment "config" of type "text/plain" (108837 bytes)