linux-kernel - Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56736BD1.5080700@linux.intel.com>
Date:	Thu, 17 Dec 2015 18:13:37 -0800
From:	Dave Hansen <dave.hansen@...ux.intel.com>
To:	Andy Lutomirski <luto@...nel.org>, Ingo Molnar <mingo@...nel.org>,
	Borislav Petkov <bp@...en8.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Brian Gerst <brgerst@...il.com>,
	Oleg Nesterov <oleg@...hat.com>
Subject: Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?

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.

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.

> 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?).

> 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.

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.

Not a huge deal, but something we want to think about, especially as it
pertains to the init/modified optimizations.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/