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: <5412.1172493721@redhat.com>
Date:	Mon, 26 Feb 2007 12:42:01 +0000
From:	David Howells <dhowells@...hat.com>
To:	Pavel Machek <pavel@....cz>
Cc:	Markus Gutschke <markus@...gle.com>,
	"Kawai, Hidehiro" <hidehiro.kawai.ez@...achi.com>,
	Andrew Morton <akpm@...l.org>,
	kernel list <linux-kernel@...r.kernel.org>,
	Robin Holt <holt@....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 

Pavel Machek <pavel@....cz> wrote:

> By same argument, we should just give up the coredumping in kernel. It
> is rarely tested, so someone will just get it wrong.

Not so rare...  Lots of people still use Evolution after all:-)

However, to counter your point, I'll point out that there's just one main code
path to do coredumping in the kernel (for ELF; there are other binfmts that do
coredumping too), as opposed to lots of applications all trying to set up
coredumping themselves.

> Remember: we are having people with huge apps, and therefore huge
> coredumps. They want to hack a kernel in ugly way to make their dumps
> smaller.

MMAP_NODUMP or  MADV_NODUMP might be better.  Let the apps mark out for
themselves what they want.

> ...but there's better solution for them, create (& debug) userland
> coredumping library. No need to hack a kernel.

Actually, a better way to do this may be similar the way I assume Windows to
work.  On fatal fault: start up a debugger and PT_ATTACH corpse to it.  The
debugger could then be something that'll just save the core.  No need to make
sure you link in the core dumping library which might not catch the event if
it's bad enough as it's working from *inside* the program, and so is subject
to being corrupted by beserk code.

David
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ