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.han...@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-devel@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
