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 229692FFF97; Wed, 18 Feb 2026 17:31:02 +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=1771435863; cv=none; b=chKdzmevos8ixDeNGaLgh3pVcQHrkWLc+XAjdigekDe6tRKjfhrsdMFc3KeAIoPHMWNaME/pEdcP6FTr/Ubwm8dfvYYUmK53q6TF55xhokgFTbnldccIcA7oEtTS4LhKiT7D+Wvg2MPZ3igv0AM21K/NqLYLUiYS2ha9BMy3beA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771435863; c=relaxed/simple; bh=ohdYdo9+SBYLGFQheyzJQWf2ZP0wlboQxRYJXiSxQpA=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=u+B92KL6v+4AI/oezXyljBGsNePTFhAWB8OcpfB6CKztQEMx+mgjHCzv30c/JcQZWpKjYzP4Tvq6N7724IvaP/CnTH08m7kBy3ReLQs/TeDPueNfhqQus5lGIuVUJFbZtAAhgRYRFeyg/UIWYKdmx88lY9rubcfFBeD0I6jl6xY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ICFm9DGk; 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="ICFm9DGk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 218D3C19425; Wed, 18 Feb 2026 17:31:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771435862; bh=ohdYdo9+SBYLGFQheyzJQWf2ZP0wlboQxRYJXiSxQpA=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=ICFm9DGkhYGoZm1Hm2GXWdOKuTAN+epLKbnBbB1UVRPUOjyJi3X+YtQVvi+VoTvQ6 kEFmWBcGWaxXNrEt54md00f2GjcXdY11bBgGpSNNC/TZFrO/kMzKdxvhAcAfk4tE/0 LpZMKcvYVSL/Qpso1QObNstDGMOwJfeNCRQiQYzN1sw7LSs10KwWFamzgQL2b0Svs/ Is+DZLmnkzUsVM9KT9OZiPbZLWJhED/CTgcj6doPsHLZdqrTF8sqcxcJDz5c1cSSYU uj5KVTQyCMipdd78j8dZ4ViP6i2Fuqj6ZFIl5E6/NyQhhY5nZb35D+auCxfIAqWeuY prrQAWLkSB2xg== Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id ECEEFF4006A; Wed, 18 Feb 2026 12:31:00 -0500 (EST) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-01.internal (MEProxy); Wed, 18 Feb 2026 12:31:00 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvvdefvdegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedftehrugcu uehivghshhgvuhhvvghlfdcuoegrrhgusgeskhgvrhhnvghlrdhorhhgqeenucggtffrrg htthgvrhhnpedvueehiedtvedtleekuddutefgffdtleetfeetveejveejieehfefhjeei jeefudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe grrhguodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduieejtdehtddtjeel qdeffedvudeigeduhedqrghruggspeepkhgvrhhnvghlrdhorhhgseifohhrkhhofhgrrh gurdgtohhmpdhnsggprhgtphhtthhopeefuddpmhhouggvpehsmhhtphhouhhtpdhrtghp 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 BAF30700065; Wed, 18 Feb 2026 12:31:00 -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: Wed, 18 Feb 2026 18:30:39 +0100 From: "Ard Biesheuvel" To: "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 Cc: "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "H . Peter Anvin" , mjg59@srcf.ucam.org, James.Bottomley@hansenpartnership.com, peterhuewe@gmx.de, "Jarkko Sakkinen" , jgg@ziepe.ca, luto@amacapital.net, 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: <242a0462-7fc5-4902-b71d-22cf8360239e@app.fastmail.com> In-Reply-To: <49d169bf-0ad2-49be-b7d7-fceb9e7f831a@app.fastmail.com> References: <20251215233316.1076248-1-ross.philipson@oracle.com> <1ffd3cb5-2c76-4371-a067-3e4849907d80@apertussolutions.com> <49d169bf-0ad2-49be-b7d7-fceb9e7f831a@app.fastmail.com> Subject: Re: [PATCH v15 00/28] x86: Secure Launch support for Intel TXT Content-Type: text/plain Content-Transfer-Encoding: 7bit On Thu, 12 Feb 2026, at 21:39, Ard Biesheuvel wrote: > On Thu, 12 Feb 2026, at 20:49, Daniel P. Smith wrote: >> On 2/9/26 09:04, Ard Biesheuvel wrote: > ... >>> I've had a stab at implementing all of this in a manner that is more idiomatic for EFI boot: >>> >>> - GRUB does minimal TXT related preparation upfront, and exposes the remaining functionality via a protocol that is attached to the loaded image by GRUB >>> - The SL stub is moved to the core kernel, with some startup code added to pivot to long mode >>> - the EFI stub executes and decompresses the kernel as usual >>> - if the protocol is present, the EFI stub calls it to pass the bootparams pointer, the base and size of the MLE and the header offset back to the GRUB code >>> - after calling ExitBootServices(), it calls another protocol method to trigger the secure launch. >>> > ... >> >> I think this is a great approach for UEFI, though we need to reconcile >> this with non-UEFI situations such as booting under coreboot. > > There are two approaches that I think are feasible for coreboot in this model: > > - just unpack the ELF and boot that - there is already prior art for > that with Xen. We can stick the MLE header offset in an ELF note where > any loader can find it. > > - stick with the current approach as much as possible, i.e., disable > physical KASLR so that the decompressed kernel will end up right where > the decompressor was loaded, which allows much of the secure launch > preparation to be done as before. Only the final bits (including the > call into the ACM itself) need to be deferred, and we can propose a > generic mechanism for that via boot_params. > > I'm working on a prototype of the latter, but GRUB is an odd beast and > my x86 fu is weak. > I've managed to get a working implementation of the legacy entrypoint, by repurposing the dl_handler() entrypoint you added for EFI [which no longer needs it in my version] as a callback for the legacy boot flow. This /should/ work for i386-coreboot too, but I have no way of testing it (I only tried 'slaunch --legacy-linux' using the x86_64-efi build). I've pushed the changes to the branches I mentioned previously in this thread.