All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sohil Mehta <sohil.mehta@intel.com>
To: <x86@kernel.org>, Dave Hansen <dave.hansen@linux.intel.com>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "Borislav Petkov" <bp@alien8.de>,
	Ard Biesheuvel <ardb@kernel.org>
Cc: "H . Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	"Kirill A . Shutemov" <kas@kernel.org>,
	Rick Edgecombe <rick.p.edgecombe@intel.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Tony Luck <tony.luck@intel.com>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	<linux-kernel@vger.kernel.org>, <linux-efi@vger.kernel.org>,
	"Maciej Wieczor-Retman" <m.wieczorretman@pm.me>
Subject: Re: [PATCH v2 0/3] x86: Extend LASS support to EFI configurations
Date: Tue, 24 Feb 2026 10:45:54 -0800	[thread overview]
Message-ID: <b476c206-08f0-4582-a924-2164ba6ae84b@intel.com> (raw)
In-Reply-To: <20260120234730.2215498-1-sohil.mehta@intel.com>

Hello x86 Maintainers, Ard,

On 1/20/2026 3:47 PM, Sohil Mehta wrote:
> Solution
> --------
> These patches take LASS out of the path of all EFI boot and runtime
> service interactions by:
> 
>   Patch 1: Deferring LASS enabling until userspace comes up, which
>   ensures EFI has completed switching to virtual mode and all boot
>   services memory has been freed [3]. 
> 
>   Patch 2: Temporarily disabling LASS every time a runtime service is
>   executed after boot. Runtime services execute in a special efi_mm
>   which doesn't have userspace mapped. So, the security implications of
>   disabling LASS are fairly limited [4].
> 

The patches now have tested-by tags from Maciej and Tony. Also, the
patches apply cleanly on v7.0-rc1. I am hoping to get some review
feedback on the patches before resending another version.

Ard, are you okay with patch 2 that disables LASS during EFI runtime calls?

x86 Maintainers, patch 1 introduces a common mechanism to defer
initializing features until userspace is about to come up. In the
future, enabling of features (such as SMAP, SMEP, UMIP) and CR pinning,
SPEC_CTRL MSR can be moved here.

Also, there is a possibility that the freeing of EFI boot services
memory might happen later based on the recent discussion at:
https://lore.kernel.org/lkml/20260223075219.2348035-1-rppt@kernel.org/

Overall, the approach in patch 1 seems useful. The implementation is
based on a combination of late_initcall() and CPU hotplug callbacks.
Thoughts?



  parent reply	other threads:[~2026-02-24 18:46 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-20 23:47 [PATCH v2 0/3] x86: Extend LASS support to EFI configurations Sohil Mehta
2026-01-20 23:47 ` [PATCH v2 1/3] x86/cpu: Defer LASS enabling until userspace comes up Sohil Mehta
2026-02-19 21:02   ` Sohil Mehta
2026-03-03 17:41     ` Dave Hansen
2026-03-03 23:59   ` [tip: x86/cpu] " tip-bot2 for Sohil Mehta
2026-01-20 23:47 ` [PATCH v2 2/3] x86/efi: Disable LASS while executing runtime services Sohil Mehta
2026-03-03 23:59   ` [tip: x86/cpu] " tip-bot2 for Sohil Mehta
2026-01-20 23:47 ` [PATCH v2 3/3] x86/cpu: Remove LASS restriction on EFI Sohil Mehta
2026-03-03 23:59   ` [tip: x86/cpu] " tip-bot2 for Sohil Mehta
2026-02-04 17:08 ` [PATCH v2 0/3] x86: Extend LASS support to EFI configurations Maciej Wieczor-Retman
2026-02-05 17:47 ` Luck, Tony
2026-02-24 18:45 ` Sohil Mehta [this message]
2026-02-24 18:49   ` Ard Biesheuvel
2026-03-03 17:42   ` Dave Hansen
  -- strict thread matches above, loose matches on Subject: below --
2026-02-04 17:03 Maciej Wieczor-Retman

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=b476c206-08f0-4582-a924-2164ba6ae84b@intel.com \
    --to=sohil.mehta@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=kas@kernel.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=m.wieczorretman@pm.me \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rick.p.edgecombe@intel.com \
    --cc=tglx@linutronix.de \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.