Message-ID: <fbb23ee0-c0b4-4b0e-8861-940f8ceaf161@intel.com>
Date: Mon, 28 Apr 2025 17:56:36 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Daniel P. Smith" <dpsmith@...rtussolutions.com>,
 Rich Persaud <persaur@...il.com>
Cc: Ross Philipson <ross.philipson@...cle.com>, linux-kernel@...r.kernel.org,
 x86@...nel.org, linux-integrity@...r.kernel.org, linux-doc@...r.kernel.org,
 linux-crypto@...r.kernel.org, kexec@...ts.infradead.org,
 linux-efi@...r.kernel.org, iommu@...ts.linux.dev, tglx@...utronix.de,
 mingo@...hat.com, bp@...en8.de, hpa@...or.com, dave.hansen@...ux.intel.com,
 ardb@...nel.org, mjg59@...f.ucam.org, James.Bottomley@...senpartnership.com,
 peterhuewe@....de, jarkko@...nel.org, jgg@...pe.ca, luto@...capital.net,
 nivedita@...m.mit.edu, herbert@...dor.apana.org.au, davem@...emloft.net,
 corbet@....net, ebiederm@...ssion.com, dwmw2@...radead.org,
 baolu.lu@...ux.intel.com, kanth.ghatraju@...cle.com,
 andrew.cooper3@...rix.com, trenchboot-devel@...glegroups.com,
 Sergii Dmytruk <sergii.dmytruk@...eb.com>, openxt@...glegroups.com,
 "Mowka, Mateusz" <mateusz.mowka@...el.com>, Ning Sun <ning.sun@...el.com>,
 tboot-devel@...ts.sourceforge.net
Subject: Re: [PATCH v14 00/19] x86: Trenchboot secure dynamic launch Linux
 kernel support

On 4/28/25 17:04, Daniel P. Smith wrote:
>> OK, but why do this in Linux as opposed to tboot? Right now, much of the
>> TXT magic is done outside of the kernel. Why do it *IN* the kernel?
> 
> There was a patch set submitted to tboot to add AMD support. It was
> rejected as tboot is solely focused on Intel TXT implementation.
> 
> This meant I either had to go the route of yet another standalone loader
> kernel or do it in the kernel. Doing it as an external loader would have
> required a new set of touchpoints, like the one you are highlighting. At
> which point, I am sure I would have gotten the question of why I didn't
> do it in the kernel.
> 
> But the real motivation for doing it in the kernel is due to Linux's
> flexibility, allowing for it to be used in a variety of use-cases. For
> instance, Linux is used as a bootloader kernel (see LinuxBoot) allowing
> for the starting of the target OS kernel from the hardware D-RTM trust
> chain. It can be used in the kexec path to again root the follow-on
> kernel in the hardware D-RTM instead of an elongated S-RTM trust chain.
> I gave a presentation at LPC 2020[1] covering several use cases if you
> are interested.
> 
> [1] https://lpc.events/event/7/contributions/739/

Could we please get a condensed version of that into the cover letter
and documentation?

But, in the end, this is a change in direction. I don't think what you
have here sufficiently justifies the move from an exokernel to the
in-kernel approach.

I'm open to hearing more, but the justification just isn't here.

>> Say we axed tboot support from 6.16, but merged Trenchboot. A user on
>> old hardware upgrades their kernel. What happens to them?
> 
> I would not advocate for the remove of tboot support.

Humor me, please.

What has to happen for Trenchboot to replace tboot if a user is already
using tboot?

You might not thing it's reasonable and so don't want to answer my
question. But I'm not the expert here. I don't know why it's not feasible.

>>>> so that Linux support for TXT/tboot can just go away?
>> You didn't _really_ answer the question.
>>
>> Summarizing, I think you're saying that TXT/tboot Linux support can just
>> go away, but it will be help if its maintainers help its users
>> transition.
>>
>> Does anybody disagree with that?
> 
> As the lead of the TrenchBoot project, I would not call for the removal
> of tboot. We did a lot of collaboration with the previous tboot
> maintainer, assisting each other with our solutions. Some may want to
> use TXT under the Exo-kernel model that tboot provides. This is one use
> case where Linux could work in that fashion but would be extremely less-
> than-ideal. Likewise, it would not be ideal to try to add a bunch of
> drivers to tboot in order to support the advanced policy-based
> environment measurement system that can be achieved with a Linux
> configuration.

This is a bit hand-wavy for my taste.

Can you give one concrete example of something that's hard or impossible
with tboot but is easy with Trenchboot?

>>> In that perfect world, Intel ACM and tboot developers would review
>>> the TrenchBoot Linux series
>>
>> So, I was looking on the cc list and I didn't see them on there.
>> Shouldn't they be cc'd if you want them to review the series? A little
>> poking at lore makes me think that they were *NEVER* cc'd.
>>
>> Is that right, or is my lore-foo weak?
> 
> As I mentioned, we did a significant amount of collaboration with Lukasz
> Hawrylko when he was the sole tboot maintainer for Intel. By the time he
> moved on, TB was fairly well complete, and at that point the goal was to
> get it to an acceptable state for the maintainers. We would be more than
> glad to have the current tboot maintainers review it if they would like.
Here's the deal: I want *an* ack from the tboot MAINTAINER on at least
one patch in this patch set. There's not a chance that we merge
duplicate, parallel in-kernel functionality without them saying that
this is a reasonable approach.

Let me know if I can help facilitate that in any way.

I kinda wish that someone would have told me a few years ago that if
tboot didn't take your patches that a 5,000-line series was going to
plop into my inbox a dozen or more times.

Powered by blists - more mailing lists