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 17:06:17 -0800 Message-ID: <4F459109.1060205@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> <4F45887A.5010809@zytor.com> 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: Roland McGrath Cc: Kees Cook , 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, 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:50 PM, Roland McGrath wrote: > On Wed, Feb 22, 2012 at 4:29 PM, H. Peter Anvin wrote: >> Can we really introduce force-kill semantics for a POSIX-defined signal? >> Other user space programs might use it for other purposes. > > The semantics are based on how the signal was generated, not what signal > number it was. The only thing that depends on the signal number is > SYNCHRONOUS_MASK, which just determines in which order pending signals are > dequeued (POSIX says it may be any order). We only have that so your state > doesn't get unhelpfully warped to another signal handler entry point > (including fiddling the stack) before you dump core. > > No use of SIGSYS is specified by POSIX at all, of course, since "system > call" is an implementation concept below the level POSIX specifies. I meant whether or not a signal can be blocked/caught and the fact that the signal exists at all. Now I guess we could have "blockable" and "unblockable" SIGSYS, but that would seem to have its own set of issues... -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]:53439 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753413Ab2BWBHH (ORCPT ); Wed, 22 Feb 2012 20:07:07 -0500 Message-ID: <4F459109.1060205@zytor.com> Date: Wed, 22 Feb 2012 17:06:17 -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> <4F45887A.5010809@zytor.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Roland McGrath Cc: Kees Cook , 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, 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: <20120223010617.MVYvue6z1QMrs2l1U7NBQHYTQzwgYtjBosoKbQ8Sesw@z> On 02/22/2012 04:50 PM, Roland McGrath wrote: > On Wed, Feb 22, 2012 at 4:29 PM, H. Peter Anvin wrote: >> Can we really introduce force-kill semantics for a POSIX-defined signal? >> Other user space programs might use it for other purposes. > > The semantics are based on how the signal was generated, not what signal > number it was. The only thing that depends on the signal number is > SYNCHRONOUS_MASK, which just determines in which order pending signals are > dequeued (POSIX says it may be any order). We only have that so your state > doesn't get unhelpfully warped to another signal handler entry point > (including fiddling the stack) before you dump core. > > No use of SIGSYS is specified by POSIX at all, of course, since "system > call" is an implementation concept below the level POSIX specifies. I meant whether or not a signal can be blocked/caught and the fact that the signal exists at all. Now I guess we could have "blockable" and "unblockable" SIGSYS, but that would seem to have its own set of issues... -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.