[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 22 Feb 2012 16:11:01 -0800
From: Roland McGrath <mcgrathr@...gle.com>
To: Andrew Lutomirski <luto@....edu>
Cc: Will Drewry <wad@...omium.org>, Indan Zupancic <indan@....nu>, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
kernel-hardening@...ts.openwall.com, netdev@...r.kernel.org, x86@...nel.org,
arnd@...db.de, davem@...emloft.net, hpa@...or.com, mingo@...hat.com,
oleg@...hat.com, peterz@...radead.org, rdunlap@...otime.net,
tglx@...utronix.de, eparis@...hat.com, serge.hallyn@...onical.com,
djm@...drot.org, scarybeasts@...il.com, pmoore@...hat.com,
akpm@...ux-foundation.org, corbet@....net, eric.dumazet@...il.com,
markus@...omium.org, keescook@...omium.org
Subject: Re: [PATCH v10 07/11] signal, x86: add SIGSYS info and make it synchronous.
On Wed, Feb 22, 2012 at 3:38 PM, Andrew Lutomirski <luto@....edu> wrote:
> I wonder if it would be helpful to change the semantics of RET_KILL
> slightly. Rather than killing via do_exit, what if it killed via a
> forcibly-fatal SIGSYS? That way, the parent's waitid() / SIGCHLD
> would indicate CLD_KILLED with si_status == SIGSYS. The parent could
> check that and report that the child was probably compromised.
That would be better. But it is certainly a more complex code path, which
makes the security weenies twitch. As to concrete issues, any "normal"
path needs the changes that are maybe pending from Oleg to make it actually
abort the syscall instead of completing it before getting to the signal path.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
