lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <03d0db6b-628e-4a5e-8e71-852233b83f60@apertussolutions.com>
Date: Mon, 28 Apr 2025 20:04:31 -0400
From: "Daniel P. Smith" <dpsmith@...rtussolutions.com>
To: Dave Hansen <dave.hansen@...el.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

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.hansen@...el.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.sun@...el.com> L:      tboot-devel@...ts.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ