linux-kernel - Re: [PATCH 0/4] coredump: core dump masking support v3

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: <45DFB1C7.1030205@google.com>
Date:	Fri, 23 Feb 2007 19:32:23 -0800
From:	Markus Gutschke <markus@...gle.com>
To:	"Kawai, Hidehiro" <hidehiro.kawai.ez@...achi.com>
CC:	Andrew Morton <akpm@...l.org>,
	kernel list <linux-kernel@...r.kernel.org>,
	Pavel Machek <pavel@....cz>, Robin Holt <holt@....com>,
	dhowells@...hat.com, Alan Cox <alan@...rguk.ukuu.org.uk>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	sugita <yumiko.sugita.yf@...achi.com>,
	Satoshi OSHIMA <soshima@...hat.com>
Subject: Re: [PATCH 0/4] coredump: core dump masking support v3

Kawai, Hidehiro wrote:
> This patch series is version 3 of the core dump masking feature,
> which provides a per-process flag not to dump anonymous shared
> memory segments.

I just wanted to remind you that you need to be careful about dumping 
the [vdso] segment no matter whether you omit other segments. I didn't 
actually try running your patches, and if the kernel doesn't actually 
consider this segment anonymous and shared, things might already work 
fine as is.

In any case, you can check with "readelf -a", if the [vdso] segment is 
there. And you will find that if you forget to dump it, "gdb" can no 
longer give you stack traces on call chains that involve signal handlers.

As an alternative to your kernel patch, you could achieve the same goal 
in user space, by linking my coredumper 
http://code.google.com/p/google-coredumper/ into your binaries and 
setting up appropriate signal handlers. An equivalent patch for 
selectively omitting memory regions would be trivial to add. While this 
does give you more flexibility, it of course has the drawback of 
requiring you to change your applications, so there still is some 
benefit in a kernelspace solution.

Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/