Message-Id: <20230110055204.3227669-1-yian.chen@intel.com>
Date:   Mon,  9 Jan 2023 21:51:57 -0800
From:   Yian Chen <yian.chen@...el.com>
To:     linux-kernel@...r.kernel.org, x86@...nel.org,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ravi Shankar <ravi.v.shankar@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        Sohil Mehta <sohil.mehta@...el.com>,
        Paul Lai <paul.c.lai@...el.com>,
        Yian Chen <yian.chen@...el.com>
Subject: [PATCH 0/7]  Enable LASS (Linear Address space Separation)

LASS (Linear Address Space Separation) is a security
extension that prevents speculative address accesses across 
user/kernel mode. The LASS details have been published in
Chapter 11 in 
https://cdrdv2.intel.com/v1/dl/getContent/671368

LASS works in 64-bit mode only and partitions the 64-bit
virtual address space into two halves:
    1. Lower half (LA[63]=0) --> user space
    2. Upper half (LA[63]=1) --> kernel space
When LASS is enabled, a general protection #GP(0) fault will
be generated if software accesses the address from the half in
which it resides to another half, e.g., either from user space
to upper half, or from kernel space to lower half. This
protection applies to data access, code execution, cache line
flushing instructions.

Almost all kernel accesses are to the upper half of the virtual
address space. However, there are valid reasons for kernel to
access the lower half. For these cases,  kernel can temporarily
suspend the enforcement of LASS by disabling SMAP (Supervisor
Mode Access Prevention).

Kernel access to copy data to/from user addresses already
disables SMAP using the stac()/clac() functions. New functions
low_addr_access_begin()/low_addr_access_end() are added to
also disable/enable SMAP around other code that legitimately
needs to access the lower half of the virtual address space.

User space cannot use any kernel address while LASS is
enabled. Less fortunately, legacy vsyscall functions used
by old version of glibc are located in the address range
0xffffffffff600000-0xffffffffff601000 and emulated in kernel.
Therefore, to comply with LASS policy, the legacy vsyscall is
disabled by default. I am looking for input from Andy and
others if this approach is acceptable.

This patch set by default enforces LASS when the platform
supports it. It can be disabled via the command line parameter
"clearcpuid" or by setting "vsyscall=emulate/xonly".

As of now there is no publicly available CPU supporting LASS.
The first one to support LASS is Sierra Forest line. The Intel
Simics® Simulator was used as software development and testing
vehicle for this patch set.

Paul Lai (1):
  x86/kvm: Expose LASS feature to VM guest

Yian Chen (6):
  x86/cpu: Enumerate LASS CPUID and CR4 bits
  x86: Add CONFIG option X86_LASS
  x86/cpu: Disable kernel LASS when patching kernel alternatives
  x86/vsyscall: Setup vsyscall to compromise LASS protection
  x86/cpu: Enable LASS (Linear Address Space Separation)
  x86/cpu: Set LASS as pinning sensitive CR4 bit

 .../admin-guide/kernel-parameters.txt         | 12 +++++++----
 arch/x86/Kconfig                              | 10 +++++++++
 arch/x86/entry/vsyscall/vsyscall_64.c         | 14 +++++++++++++
 arch/x86/include/asm/cpufeatures.h            |  1 +
 arch/x86/include/asm/disabled-features.h      |  8 ++++++-
 arch/x86/include/asm/kvm_host.h               |  3 ++-
 arch/x86/include/asm/smap.h                   | 13 ++++++++++++
 arch/x86/include/uapi/asm/processor-flags.h   |  2 ++
 arch/x86/kernel/Makefile                      |  2 ++
 arch/x86/kernel/alternative.c                 | 21 +++++++++++++++++--
 arch/x86/kernel/cpu/common.c                  | 20 +++++++++++++++++-
 arch/x86/kvm/cpuid.c                          |  2 +-
 tools/arch/x86/include/asm/cpufeatures.h      |  1 +
 .../arch/x86/include/asm/disabled-features.h  |  8 ++++++-
 tools/objtool/arch/x86/special.c              |  2 ++
 15 files changed, 108 insertions(+), 11 deletions(-)

-- 
2.34.1

Powered by blists - more mailing lists