From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E323233468F for ; Thu, 19 Feb 2026 07:55:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771487719; cv=none; b=MhgbXi9l3IfK/v4N3qMe3YdUFw9fAWNYJLqG9MCN2zGC1Qi+dquPqTPFqdoet+/fVWi1jjPFQpX17z8OSZShM7FFJH2eIs+lBNPskhr7wC6gTHGEO4ppaRlDXDyICaaGppSqu3M3XojG7a0wu753Y2IhPn1cUWC1GVqhbFAZ64k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771487719; c=relaxed/simple; bh=pzbK4/brNz010auB9728EGVQiHeaL9TguEYVSzMvosk=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=qMbm+IECpFECaEubnFE5zMcRerEXFI/IpXpLgk7gePH/kpT3A9g5H/9GvTTmX9zWPAIWrwwTLdMnHlQS460b0hsuj+qMRGtwmn8Kwd4lKmuUvdOcPzlpBPC7gEhUGf3vqgdywRcttsLkLzunC8sm0MPDjLegGMRIILyqek7LNSQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=N4iaJjTw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="N4iaJjTw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E1EFC4AF09; Thu, 19 Feb 2026 07:55:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771487718; bh=pzbK4/brNz010auB9728EGVQiHeaL9TguEYVSzMvosk=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=N4iaJjTwhPsUSIw/0tVqi0Wuaonzo3KM0NGXPNmfYCWl/cGhFtueCK/+728B4GUrL TMh2PycyFWg34db12zB4FGynt9FkyWu9PRfK3CddxE1kwHAGS64sjh4LxW7dUDDmXe GKSJ69RqbDsPxrIm9smqPMOYgaaKz/sHVczqc4w73FExob5B2Dlg4kWeA6dSUJagmr 3S+/GlR/lmfBderEx8n8/mSdHoUajuBoNIvGcbcNcBPbF+iMmTGZxswmhxn4o1tTNx L1htvApQDN33C7pWQi2wXMCJwBJKPrIqpqxWyPVHa2H3sp/f6XnSLivaUO+nCMt0Zr jzyW4tlAgp1RA== Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id 45BADF40069; Thu, 19 Feb 2026 02:55:16 -0500 (EST) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-01.internal (MEProxy); Thu, 19 Feb 2026 02:55:16 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvvdegleejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtqhertdertdejnecuhfhrohhmpedftehrugcu uehivghshhgvuhhvvghlfdcuoegrrhgusgeskhgvrhhnvghlrdhorhhgqeenucggtffrrg htthgvrhhnpeeuteeiudeigeekjedvheduieehteetgfdtuefghfejgffhfedtleehvdeh fffhvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe grrhguodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduieejtdehtddtjeel qdeffedvudeigeduhedqrghruggspeepkhgvrhhnvghlrdhorhhgseifohhrkhhofhgrrh gurdgtohhmpdhnsggprhgtphhtthhopeefvddpmhhouggvpehsmhhtphhouhhtpdhrtghp thhtohepsghpsegrlhhivghnkedruggvpdhrtghpthhtohepnhhivhgvughithgrsegrlh humhdrmhhithdrvgguuhdprhgtphhtthhopehluhhtohesrghmrggtrghpihhtrghlrdhn vghtpdhrtghpthhtohepughpshhmihhthhesrghpvghrthhushhsohhluhhtihhonhhsrd gtohhmpdhrtghpthhtoheprghnughrvgifrdgtohhophgvrhefsegtihhtrhhigidrtgho mhdprhgtphhtthhopegurghvvghmsegurghvvghmlhhofhhtrdhnvghtpdhrtghpthhtoh epphgvthgvrhhhuhgvfigvsehgmhigrdguvgdprhgtphhtthhopehhvghrsggvrhhtsehg ohhnughorhdrrghprghnrgdrohhrghdrrghupdhrtghpthhtohepthhrvghntghhsghooh htqdguvghvvghlsehgohhoghhlvghgrhhouhhpshdrtghomh X-ME-Proxy: Feedback-ID: ice86485a:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 0E84D700065; Thu, 19 Feb 2026 02:55:16 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-integrity@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: AAnEvm6syrbF Date: Thu, 19 Feb 2026 08:54:55 +0100 From: "Ard Biesheuvel" To: "Andy Lutomirski" , "Simo Sorce" Cc: "H . Peter Anvin" , "Daniel P. Smith" , "Ross Philipson" , linux-kernel@vger.kernel.org, x86@kernel.org, linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org, linux-crypto@vger.kernel.org, kexec@lists.infradead.org, linux-efi@vger.kernel.org, iommu@lists.linux.dev, dave.hansen@linux.intel.com, "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , mjg59@srcf.ucam.org, James.Bottomley@hansenpartnership.com, peterhuewe@gmx.de, "Jarkko Sakkinen" , jgg@ziepe.ca, nivedita@alum.mit.edu, "Herbert Xu" , davem@davemloft.net, corbet@lwn.net, ebiederm@xmission.com, dwmw2@infradead.org, baolu.lu@linux.intel.com, kanth.ghatraju@oracle.com, andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com Message-Id: <558d0f28-01fb-4447-891c-2ffbf869c077@app.fastmail.com> In-Reply-To: References: <20251215233316.1076248-1-ross.philipson@oracle.com> <1ffd3cb5-2c76-4371-a067-3e4849907d80@apertussolutions.com> <49d169bf-0ad2-49be-b7d7-fceb9e7f831a@app.fastmail.com> <1BBD7449-8420-43FD-930B-A4E1BA38FFC6@zytor.com> <32e62cef7b89d9691bdd4120388ce752fd041230.camel@redhat.com> Subject: Re: [PATCH v15 00/28] x86: Secure Launch support for Intel TXT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Wed, 18 Feb 2026, at 22:54, Andy Lutomirski wrote: > On Wed, Feb 18, 2026 at 1:04=E2=80=AFPM Simo Sorce w= rote: >> >> On Wed, 2026-02-18 at 12:34 -0800, Andy Lutomirski wrote: >> > On Wed, Feb 18, 2026 at 12:29=E2=80=AFPM H. Peter Anvin wrote: >> > > >> > > On February 18, 2026 12:03:27 PM PST, Andy Lutomirski wrote: >> > > > On Thu, Feb 12, 2026 at 12:40=E2=80=AFPM Ard Biesheuvel wrote: >> > > > > >> > > > > On Thu, 12 Feb 2026, at 20:49, Daniel P. Smith wrote: >> > > > > > On 2/9/26 09:04, Ard Biesheuvel wrote: >> > > > > ... >> > > > > But would it be better to disable the runtime services by def= ault when doing a secure launch? PREEMPT_RT already does the same. >> > > > >> > > > So I have a possible way to disable EFI runtime service without= losing >> > > > the ability to write EFI vars. We come up with a simple file f= ormat >> > > > to store deferred EFI var updates and we come up with a place t= o put >> > > > it so that we find it early-ish in boot the next time around. = (This >> > > > could be done via integration with systemd-boot or shim some ot= her >> > > > boot loader or it could actually be part of the kernel.) And t= hen, >> > > > instead of writing variables directly, we write them to the def= erred >> > > > list and then update them on reboot (before TXT launch, etc). = [0] >> > > > This would be a distincly nontrivial project and would not work= for >> > > > all configurations. >> > > > >> > > > As a maybe less painful option, we could disable EFI runtime se= rvices >> > > > but have a root-writable thing in sysfs that (a) turns them bac= k on >> > > > but (b) first extends a PCR to say that they're turned back on. >> > > > >> > > > (Or someone could try running runtime services at CPL3...) >> > > > >> > > > [0] I have thought for years that Intel and AMD should do this = on >> > > > their end, too. Keep the sensitive part of SMI flash entirely = locked >> > > > after boot and, instead of using magic SMM stuff to validate th= at >> > > > write attempts have the appropriate permissions and signatures,= queue >> > > > them up as deferred upates and validate the signatures on the n= ext >> > > > boot before locking flash. >> > > > >> > > >> > > *If* a physical EFI partition exists there is a lot to be said fo= r this approach. >> > > >> > > The only issue with this that I can see is for things like networ= k or CD/DVD booting where there isn't necessarily any EFI boot partition= , it might not be writable, or it might not be persistent (e.g. http boo= ting typically uses a ramdisk, like the old Linux initrd.) >> > >> > Hmm, I guess my approach is a 100% complete nonstarter for installi= ng >> > Linux from a CD, and it's really not awesome for installing Linux f= rom >> > a USB stick. >> >> Doing any of this on a removable device feels generally like a trap. >> You get your USB disk in, try to boot, and it saves vars, but reboot >> fails for whatever reason, you plug it in another machine ... and it >> tries to "continue" from there? The amount of validation needed and >> testing for failure modes across reboots sounds really painful. > > I kind of stand by my other previous suggestion, though: > > As a maybe less painful option, we could disable EFI runtime services > but have a root-writable thing in sysfs that (a) turns them back on > but (b) first extends a PCR to say that they're turned back on. > After setting the EFI boot path to GRUB (or systemd-boot or whatever) at= installation time, what other meaningful interactions do we expect with= the EFI runtime services? And given that the secure launch is orchestrated by the bootloader , wit= h which the kernel has a backchannel via its configuration file, it shou= ld be rather straight-forward to implement the staging of variable updat= es there if we really need it.=20 Doing any of this at the EFI/spec level might lead to a situation where = the OS now has to guess which of the provided APIs to manipulate variabl= es is the least broken. Of course, for readinf variables, dumping the RT variables into a memory= buffer at boot time and exposing it via a EFI config table would be rat= her straight-forward, but it is also something I feel should be the job = of the boot component that takes part in the decision to shield the runt= ime services from the OS.