From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965264AbbLRUtY (ORCPT ); Fri, 18 Dec 2015 15:49:24 -0500 Received: from mail-ob0-f175.google.com ([209.85.214.175]:35306 "EHLO mail-ob0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932255AbbLRUtX (ORCPT ); Fri, 18 Dec 2015 15:49:23 -0500 MIME-Version: 1.0 In-Reply-To: References: <56736BD1.5080700@linux.intel.com> <5673750B.606@linux.intel.com> <567453AF.5060808@linux.intel.com> <56746774.8000707@linux.intel.com> From: Andy Lutomirski Date: Fri, 18 Dec 2015 12:49:02 -0800 Message-ID: Subject: Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? To: Linus Torvalds Cc: Dave Hansen , "H. Peter Anvin" , Oleg Nesterov , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Brian Gerst , "linux-kernel@vger.kernel.org" , Christoph Hellwig Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 18, 2015 at 12:37 PM, Linus Torvalds wrote: > On Fri, Dec 18, 2015 at 12:07 PM, Dave Hansen > wrote: >> >> But, I think it's a small one. Basically, RSP would have to pointing at >> a place which was allowed by protection keys for all of the sigframe >> setup. > > Note that the whole "stack is special" is not at all a new issue. > > It's the main reason why sigaltstack() and SS_ONSTACK exists. This is > in no way new to PKRU, people have had to handle the issue of > stack-related SIGSEGV faults for a long time. > > So any application that uses PKRU and may play games that affects the > stack, will always have to have a separate "safe stack" that it uses > for signal handling. But that is in no way PKRU-specific, it's been > the case for a lot of other memory management faults. > The trouble is that this isn't just limited to special "safe stack" SA_ONSTACK aware code. It even affects normally innocuous things. The thing that's new is that, before PKRU, the HW stack might have been unsafe in the sense that accessing it would fault and we need a different backup stack for some signals. With PKRU, we might be in a transient extra-privileged (permissive PKRU) state, and we want to tighten permissions for *all* signal deliveries so that, in case the current stack is erroneous, we don't corrupt it. Admittedly, ending up with permissive PKRU in some short sequence and corrupt RSP is likely to corrupt things no matter what the kernel does. But I don't think we want to deliver SIGALRM to a library while the main program is in a specially permissive PKRU region. IOW, I like my idea in which signal delivery always sets PKRU to the application-requested-by-syscall values and sigreturn restores it. Kinda like sigaltstack, but applies to all signals and affects PKRU instead of RSP. --Andy