From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966193AbbLRCcg (ORCPT ); Thu, 17 Dec 2015 21:32:36 -0500 Received: from mail-ob0-f180.google.com ([209.85.214.180]:35756 "EHLO mail-ob0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751991AbbLRCcf (ORCPT ); Thu, 17 Dec 2015 21:32:35 -0500 MIME-Version: 1.0 In-Reply-To: <56736BD1.5080700@linux.intel.com> References: <56736BD1.5080700@linux.intel.com> From: Andy Lutomirski Date: Thu, 17 Dec 2015 18:32:14 -0800 Message-ID: Subject: Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? To: Dave Hansen Cc: Andy Lutomirski , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , Thomas Gleixner , "linux-kernel@vger.kernel.org" , Brian Gerst , Oleg Nesterov 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 Thu, Dec 17, 2015 at 6:13 PM, Dave Hansen wrote: > On 12/17/2015 05:48 PM, Andy Lutomirski wrote: >> I think that, for PKRU in particular, we want the default signal >> handling behavior to be a bit unusual. >> >> When a signal is delivered, I think we should save the entire xstate >> including PKRU. I see no reason to do anything other than that. > > Yep, agreed. > > But what about the register state when delivering a signal? Don't we > set the registers to the init state? Do we need to preserve PKRU state > instead of init'ing it? The init state _is_ nice here because it is > permissive allows us to do something useful no matter what PKRU gets set to. I think we leave the extended regs alone. Don't we? I think that, for most signals, we want to leave PKRU as is, especially for things that aren't SIGSEGV. For SIGSEGV, maybe we want an option to reset PKRU on delivery (and then set the flag to restore on return?). In any case, I think there are a decent number of programs out there that use siglongjmp and therefore never actually hit sigreturn. They probably won't restore PKRU, so we shouldn't zero it out when delivering most signals, I think. > > But, if we leave the init state in place when entering a delivering a > signal, we _can't_ decide to (by default at least) preserve the > in-signal state. > >> When a signal returns (sigreturn is called), though, I think we should >> *not* restore PKRU. To me, PKRU seems like a global per-thread state, >> not something that signal handlers are likely to clobber and should >> therefore have restored. It's also unusual in that it doesn't fit >> into the usual xstate feature model of being a bunch of registers that >> are mostly caller-saved. >> >> Does this make sense? Should we do this? > > Well, the signal handler isn't necessarily going to clobber it, but the > delivery code already clobbers it when going to the init state. Can you point to that code? > >> We have _fpx_sw_bytes.xfeatures and _xstate._header.xfeatures. They >> appear to do more or less the same thing. > > I thought the _fpx_sw_bytes were only for 32-bit (or FXSAVE/FXRSTOR?). I thought they were everywhere. fpu/signal.c looks that way to me. I could be missing something -- this code isn't the most straightforward in the world. > >> Could we say that, for >> certain new features (e.g. PKRU), if they're not in >> _fpx_sw_bytes.xfeatures, then sigreturn will preserve the old content >> rather than copying it? User code that wants to change it on >> sigreturn would manually or the feature in to xfeatures, which would >> cause the feature to go to its init state if it's not in >> _header.xfeatures or to go into the saved state if it is in >> _header.xfeatures? > > I think we first need to decide on the state upon signal delivery. > Agreed. > A practial problem at the moment is that we always call XRSTOR (aka > copy_user_to_xregs()) with RFBM (aka 'mask') with all of the supported > xfeatures. So RFBM[i]=1 for each state, effectively. A state with > XSTATE_BV[i]=0 (aka header.xfeatures) and RFBM[i]=1 will init the state. > > We'd need to rig up the copy_user_to_xregs() to first read in > header.xfeatures and then or RFBM with it. Indeed. > > Not a huge deal, but something we want to think about, especially as it > pertains to the init/modified optimizations. Fair point. FWIW, I don't think that sigreturn performance matters all that much, so if we inadvertently lose some of the optimizations, it may not be the end of the world. I do wonder: are there any modern CPUs on which copy_user_to_xregs (as opposed to first copying to the task_struct buffer and then copy_kernel_to_xregs) is ever a win? It avoids clobbering a few cachelines and saves some memory bandwidth, but that may come at the cost of disabling the init/modified optimizations when the subsequent save on context switch hits a different VA/PA than the copy_user_to_xregs used. --Andy