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]

Date:   Sun, 13 Nov 2016 12:25:52 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Ingo Molnar <mingo@...nel.org>
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

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 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.

Well, we have to pay attention not to cripple a nice debugging feature
with security. For example, come to think of it, having a debugfs flag
doesn't help if you want to see early boot segfaults, before even being
able to log in and set that flag to 1.

So the better solution would be a kernel command line flag:

  detailed_segfault=1

This is where we could also control which segfaults to see:

  detailed_segfault=<comma_separated_uid_list>

where uid comes from task_uid() (or should it be task_euid()?). No need
for the "1" - the mere presence of the command line option is enough.

With a special option of

  detailed_segfault=*

which enables it for all.

I think that's a good compromise with security.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.