Messages in this thread | | | Date | Tue, 10 Jan 2023 11:48:41 -0800 | Subject | Re: [PATCH 0/7] Enable LASS (Linear Address space Separation) | From | Sohil Mehta <> |
| |
Yian,
I added a few missing lists pertaining to KVM, MM and documentation since these patches impact them.
In future, scripts/get_maintainer.pl can help you with generating the relevant maintainers and lists.
On 1/9/2023 9:51 PM, Yian Chen wrote: > 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 >
It's usually good practice to include a base-commit to make it easier to apply these patches.
> .../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(-) >
| |