[v13,00/16] Enable FSGSBASE instructions
mbox series

Message ID 20200528201402.1708239-1-sashal@kernel.org
Headers show
Series
  • Enable FSGSBASE instructions
Related show

Message

Sasha Levin May 28, 2020, 8:13 p.m. UTC
Benefits:
Currently a user process that wishes to read or write the FS/GS base must
make a system call. But recent X86 processors have added new instructions
for use in 64-bit mode that allow direct access to the FS and GS segment
base addresses.  The operating system controls whether applications can
use these instructions with a %cr4 control bit.

In addition to benefits to applications, performance improvements to the
OS context switch code are possible by making use of these instructions. A
third party reported out promising performance numbers out of their
initial benchmarking of the previous version of this patch series.

Enablement check:
The kernel provides information about the enabled state of FSGSBASE to
applications using the ELF_AUX vector. If the HWCAP2_FSGSBASE bit is set in
the AUX vector, the kernel has FSGSBASE instructions enabled and
applications can use them.

Kernel changes:
Major changes made in the kernel are in context switch, paranoid path, and
ptrace. In a context switch, a task's FS/GS base will be secured regardless
of its selector. In the paranoid path, GS base is unconditionally
overwritten to the kernel GS base on entry and the original GS base is
restored on exit. Ptrace includes divergence of FS/GS index and base
values.

Security:
For mitigating the Spectre v1 SWAPGS issue, LFENCE instructions were added
on most kernel entries. Those patches are dependent on previous behaviors
that users couldn't load a kernel address into the GS base. These patches
change that assumption since the user can load any address into GS base.
The changes to the kernel entry path in this patch series take account of
the SWAPGS issue.

Changes from v12:
 - Reformat the series to be closer to the reverted codebase for easier
   review.
 - Drop a few of the changes introduced in v8 and v9.


Andi Kleen (2):
  x86/fsgsbase/64: Add intrinsics for FSGSBASE instructions
  x86/elf: Enumerate kernel FSGSBASE capability in AT_HWCAP2

Andy Lutomirski (3):
  x86/cpu: Add 'unsafe_fsgsbase' to enable CR4.FSGSBASE
  x86/process/64: Use FSBSBASE in switch_to() if available
  x86/cpu: Enable FSGSBASE on 64bit by default and add a chicken bit

Chang S. Bae (8):
  x86/ptrace: Prevent ptrace from clearing the FS/GS selector
  x86/fsgsbase/64: Enable FSGSBASE instructions in helper functions
  x86/process/64: Use FSGSBASE instructions on thread copy and ptrace
  x86/entry/64: Switch CR3 before SWAPGS in paranoid entry
  x86/entry/64: Introduce the FIND_PERCPU_BASE macro
  x86/entry/64: Handle FSGSBASE enabled paranoid entry/exit
  selftests/x86/fsgsbase: Test GS selector on ptracer-induced GS base
    write
  selftests/x86/fsgsbase: Test ptracer-induced GS base write with
    FSGSBASE

Thomas Gleixner (2):
  x86/process/64: Make save_fsgs() public available
  Documentation/x86/64: Add documentation for GS/FS addressing mode

Tony Luck (1):
  x86/speculation/swapgs: Check FSGSBASE in enabling SWAPGS mitigation

 .../admin-guide/kernel-parameters.txt         |   2 +
 Documentation/x86/x86_64/fsgs.rst             | 199 ++++++++++++++++++
 Documentation/x86/x86_64/index.rst            |   1 +
 arch/x86/entry/calling.h                      |  40 ++++
 arch/x86/entry/entry_64.S                     | 135 +++++++++---
 arch/x86/include/asm/fsgsbase.h               |  45 +++-
 arch/x86/include/asm/inst.h                   |  15 ++
 arch/x86/include/asm/processor.h              |   4 +-
 arch/x86/include/uapi/asm/hwcap2.h            |   3 +
 arch/x86/kernel/cpu/bugs.c                    |   6 +-
 arch/x86/kernel/cpu/common.c                  |  22 ++
 arch/x86/kernel/process.c                     |  10 +-
 arch/x86/kernel/process_64.c                  | 119 +++++++++--
 arch/x86/kernel/ptrace.c                      |  17 +-
 arch/x86/kvm/vmx/vmx.c                        |   2 +-
 tools/testing/selftests/x86/fsgsbase.c        |  24 ++-
 16 files changed, 562 insertions(+), 82 deletions(-)
 create mode 100644 Documentation/x86/x86_64/fsgs.rst

Comments

Thomas Gleixner June 18, 2020, 2:18 p.m. UTC | #1
Sasha,

Sasha Levin <sashal@kernel.org> writes:
> Changes from v12:
>  - Reformat the series to be closer to the reverted codebase for easier
>    review.
>  - Drop a few of the changes introduced in v8 and v9.

I've pushed the lot out to

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/fsgsbase

Thanks for taking this up!

       tglx
Andy Lutomirski June 18, 2020, 6:08 p.m. UTC | #2
On Thu, Jun 18, 2020 at 7:18 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> Sasha,
>
> Sasha Levin <sashal@kernel.org> writes:
> > Changes from v12:
> >  - Reformat the series to be closer to the reverted codebase for easier
> >    review.
> >  - Drop a few of the changes introduced in v8 and v9.
>
> I've pushed the lot out to
>
>    git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/fsgsbase
>
> Thanks for taking this up!
>

Is there a plan to deal with:

        /*
         * This function has some ABI oddities.
         *
         * A 32-bit ptracer probably expects that writing FS or GS will change
         * FSBASE or GSBASE respectively.  In the absence of FSGSBASE support,
         * this code indeed has that effect.  When FSGSBASE is added, this
         * will require a special case.
         *
         * For existing 64-bit ptracers, writing FS or GS *also* currently
         * changes the base if the selector is nonzero the next time the task
         * is run.  This behavior may? not be needed, and trying to preserve it
         * when FSGSBASE is added would be complicated at best.
         */

in arch/x86/kernel/ptrace.c?
Thomas Gleixner June 18, 2020, 6:25 p.m. UTC | #3
Andy Lutomirski <luto@kernel.org> writes:
> Is there a plan to deal with:
>
>         /*
>          * This function has some ABI oddities.
>          *
>          * A 32-bit ptracer probably expects that writing FS or GS will change
>          * FSBASE or GSBASE respectively.  In the absence of FSGSBASE support,
>          * this code indeed has that effect.  When FSGSBASE is added, this
>          * will require a special case.
>          *
>          * For existing 64-bit ptracers, writing FS or GS *also* currently
>          * changes the base if the selector is nonzero the next time the task
>          * is run.  This behavior may? not be needed, and trying to preserve it
>          * when FSGSBASE is added would be complicated at best.
>          */
>
> in arch/x86/kernel/ptrace.c?

Not that I'm aware of.