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

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
	"H. Peter Anvin" <hpa@zytor.com>, Oleg Nesterov <oleg@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@kernel.org>, Borislav Petkov <bp@alien8.de>,
	Brian Gerst <brgerst@gmail.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: Rethinking sigcontext's xfeatures slightly for PKRU's benefit?
Date: Fri, 18 Dec 2015 12:37:23 -0800	[thread overview]
Message-ID: <CA+55aFycMWxCVY1p8n_D8nGz7Ky35uAmZMWm=zE5LBsqModiBg@mail.gmail.com> (raw)
In-Reply-To: <56746774.8000707@linux.intel.com>

On Fri, Dec 18, 2015 at 12:07 PM, Dave Hansen
<dave.hansen@linux.intel.com> 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.

                  Linus