[RFC][PATCH 0/8] x86/pkeys: remove PKRU from kernel XSAVE buffer

[Dave Hansen <dave.hansen@linux.intel.com>]

This is a rework of the kernel's Protection Keys Register code.  It severs
the connection between PKRU and XSAVE as thoroughly as possible without
affecting the existing ABIs.

This compiles in a few configurations and passes the pkeys selftest, but
that's about it.  It's not been pummeled enough yet for merging anywhere.

This is on top of the current:

	git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git x86/fpu

specifically:

	3d168301c78d ("x86/fpu/signal: Let xrstor handle the features to init")

--

PKRU is currently a strange beast.  It can be XSAVE-managed and it has
space allocated in the thread 'fpstate' buffer.  However, it is
switched more eagerly than other FPU state because PKRU affects things
like copy_to/from_user().  This is because PKRU affects user *PERMISSION*
accesses, not just accesses made from user *MODE* itself.

This leaves PKRU in a very odd position.  It is stored in the kernel
XSAVE buffer but the XSAVE architecture is not used to manage it.

Move PKRU out of the 'fpstate' buffer.  Instead, allocate space in the
thread_struct for it and save/restore it in the context-switch path
separately from the XSAVE-managed features.  This removes the ambiguity
of having PKRU state in two places for each task.

 include/asm/fpu/internal.h |    2 -
 include/asm/fpu/xstate.h   |    2 -
 include/asm/pkru.h         |   10 +++--
 kernel/cpu/common.c        |   19 +++++++++-
 kernel/fpu/core.c          |    8 ++--
 kernel/fpu/signal.c        |   12 +++++-
 kernel/fpu/xstate.c        |   83 ++++++++++++++++++++++++++++++---------------
 kernel/process_64.c        |    9 ++--
 kernel/signal.c            |    1 
 kvm/x86.c                  |    8 ++--
 mm/pkeys.c                 |   21 ++---------
 11 files changed, 113 insertions(+), 62 deletions(-)

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org
Cc: Andy Lutomirski <luto@kernel.org>