lkml.org 
[lkml]   [2023]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[PATCH 0/7] Enable LASS (Linear Address space Separation)
    Date
    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

    \
     
     \ /
      Last update: 2023-03-26 23:34    [W:4.152 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site