linux-kernel - Re: [RFC] SIGKILL vs. SIGSEGV on late execve() failures

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: <CAGDaZ_rqKR7Ea6SZ9JXmeVOvEBEk3gHaQEa1LAkzWxRHfJsHWw@mail.gmail.com>
Date:	Fri, 15 Feb 2013 16:38:51 -0800
From:	Shentino <shentino@...il.com>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] SIGKILL vs. SIGSEGV on late execve() failures

On Fri, Feb 15, 2013 at 4:04 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> How would you manage to have it masked at that point?  setup_new_exec()
> is inevitable after success of flush_old_exec() and it will do
> flush_signal_handlers() for us.

I wouldn't know for sure but I read somewhere that even if execve
resets handled signals, it didn't also say that ignored signals were
also reset.  (Source: execve man page.)

Plus I've always seen "force_sig" instead of "send_sig" for errors
that can't just be ignored.

Then again I'm a complete n00b at linux hacking so I could very well
be mistaken.  It just looked funny considering what I'm used to seeing
in the source.

I'm hoping this is just me being an idiot and that there's nothing to
worry about.

> And yes, flush_old_exec() and setup_new_exec() ought to be merged; the
> problem with that is the stuff done between those two - setting personality,
> plus playing with thread flags if needed.  Unfortunately, there are non-obvious
> differences between architectures, so that would have to be hashed out on
> linux-arch.  Doesn't affect the point above, though...
--
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/