Re: [PATCH v14 00/19] x86: Trenchboot secure dynamic launch Linux kernel support

[Rich Persaud]

On Apr 24, 2025, at 2:45 PM, Dave Hansen <dave....@intel.com> wrote:

On 4/21/25 09:26, Ross Philipson wrote:

This patchset provides detailed documentation of DRTM, the approach used for

adding the capbility, and relevant API/ABI documentation. In addition to the

documentation the patch set introduces Intel TXT support as the first platform

for Linux Secure Launch.

So, I know some of the story here thanks to Andy Cooper. But the
elephant in the room is:

INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)

M:      Ning Sun <ning...@intel.com>

L:      tboot...@lists.sourceforge.net

S:      Supported

W:      http://tboot.sourceforge.net

T:      hg http://tboot.hg.sourceforge.net:8000/hgroot/tboot/tboot

F:      Documentation/arch/x86/intel_txt.rst

F:      arch/x86/kernel/tboot.c

F:      include/linux/tboot.h

Linux already supports TXT. Why do we need TrenchBoot?

One reason is to generalize DRTM support to other platforms.

RFC: Trenchboot Secure Launch DRTM for AMD SKINIT 

https://lore.kernel.org/lkml/cover.1734008878....@3mdeb.com/

OpenXT measured launch usage of tboot originated in 2012, when I was the program manager for XenClient joint development [1][2] by Intel and Citrix. TrenchBoot was proposed in 2018 at Platform Security Summit and evolved [3] based on LKML and conference feedback. The tboot community was introduced [4] to TrenchBoot in 2022.

I think I know the answer, but it also needs to be a part of the
documentation, changelogs and cover letter.

Also, honestly, what do you think we should do with the Linux tboot
code? Is everyone going to be moving over to Trenchboot 

OpenXT will migrate development of measured launch from tboot to TrenchBoot Secure Launch, after upstream Linux and Xen have support for both Intel and AMD DRTM. Previously-deployed Intel devices using tboot, derived from OpenXT, will need support until users upgrade their hardware. Qubes is integrating [5] TrenchBoot into AEM (Anti Evil Maid). Since Oracle has spent several years working on this TrenchBoot series, they might use it, hopefully they can comment. 

so that Linux support for TXT/tboot can just go away?

[opinion]

Which one will prevail? That may have less to do with tboot-trenchboot differences and more to do with AMD-Intel product marketing and OEM segmentation of DRTM features, some certified by Microsoft as "Secured Core" clients with SMM attestation (Intel PPAM and AMD SMM Supervisor).

Intel requires client vPro devices for TXT, but has slowly expanded the list of eligible SKUs via "vPro Essentials" segmentation. AMD SKINIT is present on most processors, but DRTM currently requires a dTPM instead of the "mobile" fTPM implementation in AMD PSP firmware, with dTPMs mostly present in AMD OEM "PRO" or Embedded SKUs.

If AMD included the full TPM 2.0 reference code in their PSP fTPM,  or if MS Pluton implemented a full TPM 2.0 that was compatible with DRTM, then the number of AMD DRTM-capable devices would be much higher than the number of Intel vPro or AMD PRO devices, expanding the market for DRTM-capable software like Linux (trenchboot) Secure Launch and Windows SystemGuard. That would increase client adoption of trenchboot, as the only option for Linux DRTM on AMD.

On servers, both AMD and Intel hardware support DRTM with dTPM and other roots of trust, but there are other launch considerations, including BMCs, SPDM device attestation & vendor hypervisors.

[/opinion]

In a perfect world, Intel-signed ACMs (used in TXT DRTM) binary blobs would be accompanied by public read-only source code with reproducible builds that generate those ACM blobs. In that perfect world, Intel ACM and tboot developers would review the TrenchBoot Linux series, recommend improvements and guide customers on migration from tboot to upstream-supported Linux DRTM. Neither has yet happened. Both would be welcome.

Rich

[1] https://www.intel.com/content/dam/www/public/us/en/documents/success-stories/3rd-gen-core-vpro-citrix-vendor-spotlight.pdf

[2] http://media12.connectedsocialmedia.com/intel/11/9510/Air_Force_Research_Laboratory_Security_Collaboration_Government.pdf

[3] https://trenchboot.org/events/

[4] https://sourceforge.net/p/tboot/mailman/message/37631560/

[5] https://blog.3mdeb.com/2023/2023-01-31-trenchboot-aem-for-qubesos/

[Rich Persaud]

On Apr 24, 2025, at 2:45 PM, Dave Hansen <dave....@intel.com> wrote:
> On 4/21/25 09:26, Ross Philipson wrote:
>> This patchset provides detailed documentation of DRTM, the approach used for
>> adding the capbility, and relevant API/ABI documentation. In addition to the
>> documentation the patch set introduces Intel TXT support as the first platform
>> for Linux Secure Launch.
>
> So, I know some of the story here thanks to Andy Cooper. But the
> elephant in the room is:
>
>> INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT)
>> M: Ning Sun <ning...@intel.com>
>> L: tboot...@lists.sourceforge.net
>> S: Supported
>> W: http://tboot.sourceforge.net
>> T: hg http://tboot.hg.sourceforge.net:8000/hgroot/tboot/tboot
>> F: Documentation/arch/x86/intel_txt.rst
>> F: arch/x86/kernel/tboot.c
>> F: include/linux/tboot.h
>
> Linux already supports TXT. Why do we need TrenchBoot?

One reason is to generalize DRTM support to other platforms.

RFC: Trenchboot Secure Launch DRTM for AMD SKINIT
https://lore.kernel.org/lkml/cover.1734008878....@3mdeb.com/

OpenXT.org measured launch usage of tboot originated in 2012, when I was the program manager for XenClient joint development [1][2] by Intel and Citrix. TrenchBoot was proposed in 2018 at Platform Security Summit and evolved [3] based on LKML and conference feedback. The tboot community was introduced [4] to TrenchBoot in 2022.

> I think I know the answer, but it also needs to be a part of the
> documentation, changelogs and cover letter.
>
> Also, honestly, what do you think we should do with the Linux tboot
> code? Is everyone going to be moving over to Trenchboot

OpenXT will migrate development of measured launch from tboot to TrenchBoot Secure Launch, after upstream Linux and Xen have support for both Intel and AMD DRTM. Previously-deployed Intel devices using tboot, derived from OpenXT, will need support until users upgrade their hardware. Qubes is integrating [5] TrenchBoot into AEM (Anti Evil Maid). Since Oracle has spent several years working on this TrenchBoot series, they might use it, hopefully they can comment.


> so that Linux support for TXT/tboot can just go away?

[opinion]
Which one will prevail? That may have less to do with tboot-trenchboot differences and more to do with AMD-Intel product marketing and OEM segmentation of DRTM features, some certified by Microsoft as "Secured Core" clients with SMM attestation (Intel PPAM and AMD SMM Supervisor).

Intel requires client vPro devices for TXT, but has slowly expanded the list of eligible SKUs via "vPro Essentials" segmentation. AMD SKINIT is present on most processors, but DRTM currently requires a dTPM instead of the "mobile" fTPM implementation in AMD PSP firmware, with dTPMs mostly present in AMD OEM "PRO" or Embedded SKUs.

If AMD included the full TPM 2.0 reference code in their PSP fTPM, or if MS Pluton implemented a full TPM 2.0 that was compatible with DRTM, then the number of AMD DRTM-capable devices would be much higher than the number of Intel vPro or AMD PRO devices, expanding the market for DRTM-capable software like Linux (trenchboot) Secure Launch and Windows SystemGuard. That would increase client adoption of trenchboot, as the only option for Linux DRTM on AMD.

On servers, both AMD and Intel hardware support DRTM with dTPM and other roots of trust, but there are other launch considerations, including BMCs, SPDM device attestation & vendor hypervisors.
[/opinion]

In a perfect world, Intel-signed ACM (used in TXT DRTM) binary blobs would be accompanied by public read-only source code, with reproducible builds that generate those ACM blobs. In that perfect world, Intel ACM and tboot developers would review the TrenchBoot Linux series, recommend improvements and guide customers on migration from tboot to upstream-supported Linux DRTM. Neither has yet happened. Both would be welcome.

[Daniel P. Smith]

Hi Dave!

On 4/25/25 10:12, Dave Hansen wrote:
> On 4/25/25 03:12, Rich Persaud wrote:
>> On Apr 24, 2025, at 2:45 PM, Dave Hansen <dave....@intel.com>

>> wrote:
>>> On 4/21/25 09:26, Ross Philipson wrote:
>>>> This patchset provides detailed documentation of DRTM, the
>>>> approach used for adding the capbility, and relevant API/ABI
>>>> documentation. In addition to the documentation the patch set
>>>> introduces Intel TXT support as the first platform for Linux
>>>> Secure Launch.
>>>
>>> So, I know some of the story here thanks to Andy Cooper. But the
>>> elephant in the room is:
>>>
>>>> INTEL(R) TRUSTED EXECUTION TECHNOLOGY (TXT) M: Ning Sun
>>>> <ning...@intel.com> L: tboot...@lists.sourceforge.net
>>>> S: Supported W: http://tboot.sourceforge.net T: hg
>>>> http://tboot.hg.sourceforge.net:8000/hgroot/tboot/tboot F:
>>>> Documentation/arch/x86/intel_txt.rst F: arch/x86/ kernel/
>>>> tboot.c F: include/linux/tboot.h
>>>
>>> Linux already supports TXT. Why do we need TrenchBoot?
>>
>> One reason is to generalize DRTM support to other platforms.
>

> 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/

>>> Also, honestly, what do you think we should do with the Linux
>>> tboot code? Is everyone going to be moving over to Trenchboot>
>> OpenXT will migrate development of measured launch from tboot to
>> TrenchBoot Secure Launch, after upstream Linux and Xen have support
>> for both Intel and AMD DRTM. Previously-deployed Intel devices using
>> tboot, derived from OpenXT, will need support until users upgrade
>> their hardware.
>

> 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.

>>> 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.

>> 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.

V/r,
Daniel