From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH v10 07/11] signal, x86: add SIGSYS info and make it synchronous. Date: Wed, 22 Feb 2012 16:29:46 -0800 Message-ID: <4F45887A.5010809@zytor.com> References: <1329845435-2313-1-git-send-email-wad@chromium.org> <1329845435-2313-7-git-send-email-wad@chromium.org> <9edbabb2262e3d91a7b8c75dbec03d7f.squirrel@webmail.greenhost.nl> Reply-To: kernel-hardening@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: List-Post: List-Help: List-Unsubscribe: List-Subscribe: In-Reply-To: To: Kees Cook Cc: Will Drewry , Andrew Lutomirski , Indan Zupancic , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, kernel-hardening@lists.openwall.com, netdev@vger.kernel.org, x86@kernel.org, arnd@arndb.de, davem@davemloft.net, mingo@redhat.com, oleg@redhat.com, peterz@infradead.org, rdunlap@xenotime.net, mcgrathr@chromium.org, tglx@linutronix.de, eparis@redhat.com, serge.hallyn@canonical.com, djm@mindrot.org, scarybeasts@gmail.com, pmoore@redhat.com, akpm@linux-foundation.org, corbet@lwn.net, eric.dumazet@gmail.com, markus@chromium.org List-Id: linux-arch.vger.kernel.org On 02/22/2012 04:08 PM, Kees Cook wrote: >> >> Hrm, it might be possible to do_exit(SIGSYS) which would be both. It >> looks like tsk->exit_code would be SIGSYS then, but I'll look a little >> more closely to see what that'll actually do. > > As long as there's no way it can get blocked, I'd be fine with that. > It would, actually, be better than SIGKILL because, as Andy said, it's > more distinguishable from other situations. I've long wanted a signal > to be used for "violated policy" that wasn't just a straight SIGKILL. > Can we really introduce force-kill semantics for a POSIX-defined signal? Other user space programs might use it for other purposes. I'm wondering if the right thing may be to introduce some variant of exit() which can return more information about a signal, including some kind of cause code for SIGKILL? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from terminus.zytor.com ([198.137.202.10]:53311 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752536Ab2BWAat (ORCPT ); Wed, 22 Feb 2012 19:30:49 -0500 Message-ID: <4F45887A.5010809@zytor.com> Date: Wed, 22 Feb 2012 16:29:46 -0800 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [PATCH v10 07/11] signal, x86: add SIGSYS info and make it synchronous. References: <1329845435-2313-1-git-send-email-wad@chromium.org> <1329845435-2313-7-git-send-email-wad@chromium.org> <9edbabb2262e3d91a7b8c75dbec03d7f.squirrel@webmail.greenhost.nl> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Kees Cook Cc: Will Drewry , Andrew Lutomirski , Indan Zupancic , linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, kernel-hardening@lists.openwall.com, netdev@vger.kernel.org, x86@kernel.org, arnd@arndb.de, davem@davemloft.net, mingo@redhat.com, oleg@redhat.com, peterz@infradead.org, rdunlap@xenotime.net, mcgrathr@chromium.org, tglx@linutronix.de, eparis@redhat.com, serge.hallyn@canonical.com, djm@mindrot.org, scarybeasts@gmail.com, pmoore@redhat.com, akpm@linux-foundation.org, corbet@lwn.net, eric.dumazet@gmail.com, markus@chromium.org Message-ID: <20120223002946.D9qimhfmKHkzv0dNPIKWZSgoLQhyVIvVYvbZJPTg8sY@z> On 02/22/2012 04:08 PM, Kees Cook wrote: >> >> Hrm, it might be possible to do_exit(SIGSYS) which would be both. It >> looks like tsk->exit_code would be SIGSYS then, but I'll look a little >> more closely to see what that'll actually do. > > As long as there's no way it can get blocked, I'd be fine with that. > It would, actually, be better than SIGKILL because, as Andy said, it's > more distinguishable from other situations. I've long wanted a signal > to be used for "violated policy" that wasn't just a straight SIGKILL. > Can we really introduce force-kill semantics for a POSIX-defined signal? Other user space programs might use it for other purposes. I'm wondering if the right thing may be to introduce some variant of exit() which can return more information about a signal, including some kind of cause code for SIGKILL? -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.