linux-kernel - 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-next>] [day] [month] [year] [list]

Date:	Thu, 17 Dec 2015 17:48:56 -0800
From:	Andy Lutomirski <luto@...nel.org>
To:	Dave Hansen <dave.hansen@...ux.intel.com>,
	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: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?

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