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

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


             reply	other threads:[~2023-01-10  5:57 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-10  5:51 Yian Chen [this message]
2023-01-10  5:51 ` [PATCH 1/7] x86/cpu: Enumerate LASS CPUID and CR4 bits Yian Chen
2023-01-10 20:14   ` Sohil Mehta
2023-01-11  0:13     ` Dave Hansen
2023-01-11 23:23       ` Chen, Yian
2023-01-12  0:06         ` Luck, Tony
2023-01-12  0:15           ` Chen, Yian
2023-01-11 19:21     ` Chen, Yian
2023-01-10  5:51 ` [PATCH 2/7] x86: Add CONFIG option X86_LASS Yian Chen
2023-01-10 21:05   ` Sohil Mehta
2023-01-12  0:13     ` Chen, Yian
2023-01-10  5:52 ` [PATCH 3/7] x86/cpu: Disable kernel LASS when patching kernel alternatives Yian Chen
2023-01-10 21:04   ` Peter Zijlstra
2023-01-11  1:01     ` Chen, Yian
2023-01-11  9:10       ` Peter Zijlstra
2023-01-10 22:41   ` Sohil Mehta
2023-01-12  0:27     ` Chen, Yian
2023-01-12  0:37       ` Dave Hansen
2023-01-12 18:36         ` Chen, Yian
2023-01-12 18:48           ` Dave Hansen
2023-02-01  2:25             ` Sohil Mehta
2023-02-01 18:20               ` Dave Hansen
2023-02-01  2:10         ` Sohil Mehta
2023-01-10  5:52 ` [PATCH 4/7] x86/vsyscall: Setup vsyscall to compromise LASS protection Yian Chen
2023-01-11  0:34   ` Sohil Mehta
2023-01-12  1:43     ` Chen, Yian
2023-01-12  2:49       ` Sohil Mehta
2023-01-21  4:09   ` Andy Lutomirski
2023-01-10  5:52 ` [PATCH 5/7] x86/cpu: Enable LASS (Linear Address Space Separation) Yian Chen
2023-01-11 22:22   ` Sohil Mehta
2023-01-12 17:56     ` Chen, Yian
2023-01-12 18:17   ` Dave Hansen
2023-01-13  1:17     ` Sohil Mehta
2023-01-13 19:39       ` Sohil Mehta
2023-01-10  5:52 ` [PATCH 6/7] x86/cpu: Set LASS as pinning sensitive CR4 bit Yian Chen
2023-01-10  5:52 ` [PATCH 7/7] x86/kvm: Expose LASS feature to VM guest Yian Chen
2023-02-07  3:21   ` Wang, Lei
2023-02-09 17:18     ` Sean Christopherson
2023-01-10 19:48 ` [PATCH 0/7] Enable LASS (Linear Address space Separation) Sohil Mehta
2023-01-10 22:57 ` Dave Hansen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230110055204.3227669-1-yian.chen@intel.com \
    --to=yian.chen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=paul.c.lai@intel.com \
    --cc=ravi.v.shankar@intel.com \
    --cc=sohil.mehta@intel.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).