linux-kernel - Re: [PATCH] exec: Make do_coredump more robust and safer when using pipes in core

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 1 Aug 2009 20:22:17 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Scott James Remnant <scott@...ntu.com>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	earl_chew@...lent.com
Subject: Re: [PATCH] exec: Make do_coredump more robust and safer when
	using pipes in core_pattern

On Sat, Aug 01, 2009 at 07:28:52PM +0100, Scott James Remnant wrote:
> On Sat, 2009-08-01 at 09:41 -0400, Neil Horman wrote:
> 
> > > > Not without additional work.  If init crashed in the initramfs, I don't think
> > > > theres a way to handle that.  If it crashes at some later time, I think it just
> > > > gets restarted IIRC.  I'm sure you can change that behavior, but this patch
> > > > doesn't address that.
> > > > 
> > > When the system init daemon crashes, the kernel PANICs.  When not using
> > > core_pattern, this is ok, we get a core file - when using apport, as far
> > > as I can tell it never waits for apport to finish so we don't get the
> > > crash.
> > > 
> > This is non-sensical.  If init crashes, and the kernel panics, you'll only get a
> > core by sheer luck and good fortune.
> > 
> Or by being a bit clever.  Upstart catches the SIGSEGV and the signal
> handler forks a child process, unmasking the signal in that child
> process with no signal handler installed.
> 
I don't see how this works.  How is upstart (which by definition is a child of
init (pid 1)) going to catch a SIGSEGV from its parent?  How would any process
catch a signal targeted to its parent?

> So it's really a child of init that core dumps, just ignore the signal
> handler off the top of the stack trace and it's just as good as a core
> dump from the init daemon itself.
> 
Ok, setting asside that I don't see how you can do what your describing above,
if you're forking a crashing process so that it crashes in exactly the same way,
that makes a bit of sense.

> Meanwhile the real init daemon (pid 1) wait()s on its child, and then
> once it's reaped it exits itself - and then the kernel PANICs.
> 
> 
> This works just fine with ordinary core files, because the kernel does
> at least write out the core file beforehand.  With apport we don't get
> this wait, thus I was hoping your patch would have that effect.
> 
Well, again setting asside that I don't see how you're doing what you say above,
my patch does what you're hoping it does.  It can be configured to wait on the
crashing processes until its the pipe reader is exited.

Neil

> Scott
> -- 
> Scott James Remnant
> scott@...ntu.com


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