From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965435AbbLRBtU (ORCPT ); Thu, 17 Dec 2015 20:49:20 -0500 Received: from mail.kernel.org ([198.145.29.136]:33843 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964900AbbLRBtT (ORCPT ); Thu, 17 Dec 2015 20:49:19 -0500 MIME-Version: 1.0 From: Andy Lutomirski Date: Thu, 17 Dec 2015 17:48:56 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Rethinking sigcontext's xfeatures slightly for PKRU's benefit? To: Dave Hansen , 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 Hi all- 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. 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? We have _fpx_sw_bytes.xfeatures and _xstate._header.xfeatures. They appear to do more or less the same thing. 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? Other means of signaling this could work, too. It's not all that much code, I think. --Andy