Thread (28 messages) flat view 28 messages, 6 authors, 2022-02-15

Re: [PATCH v4 00/14] x86: Trenchboot secure dynamic launch Linux kernel support

From: Paul Moore <paul@paul-moore.com>
Date: 2021-12-06 20:56:58
Also in: linux-integrity, linux-iommu, lkml

On Thu, Dec 2, 2021 at 11:11 AM Daniel P. Smith
[off-list ref] wrote:
Hi Paul!
/me waves
On 11/30/21 8:06 PM, Paul Moore wrote:
quoted
On Fri, Aug 27, 2021 at 9:20 AM Ross Philipson
[off-list ref] wrote:
quoted
The larger focus of the Trechboot project (https://github.com/TrenchBoot) is to
enhance the boot security and integrity in a unified manner. The first area of
focus has been on the Trusted Computing Group's Dynamic Launch for establishing
a hardware Root of Trust for Measurement, also know as DRTM (Dynamic Root of
Trust for Measurement).
My apologies for such a late reply, but I'm just getting around to
looking at this and I have a few questions on the basic design/flow
(below) ...
No worries, thank you so much for taking the time to review.
quoted
quoted
The basic flow is:

 - Entry from the dynamic launch jumps to the SL stub
So I'm clear, at this point the combined stub+kernel+initramfs+cmdline
image has already been loaded into memory and the SL stub is
executing, yes?
That is correct.
quoted
As TrenchBoot seems to be focused on boot measurement and not
enforcing policy, I'm guessing this is considered out-of-scope (not to
mention that the combined stub+kernel image makes this less
interesting), but has any thought been given to leveraging the TXT
launch control policy, or is it simply an empty run-everything policy?
The TrenchBoot model is a bit different and takes a more flexible
approach to allow users to build tailored solutions. For instance Secure
Launch is able to be used in a configuration that is similar to tboot.
Consider the functions of tboot, it has a portion that is the
post-launch kernel that handles the handover from the ACM and a portion
that provides the Verified Launch policy engine, which is only capable
of enforcing policy on what is contained in the Multiboot chain. The
TrenchBoot approach is to introduce the Secure Launch capability into a
kernel, in this case Linux, to handle the handover from the ACM, and
then transition to a running user space that can contain a distribution
specific policy enforcement. As an example, the TrenchBoot project
contributed to the uroot project a Secure Launch policy engine which
enables the creation of an initramfs image which can then be embedded
into a minimal configuration Secure Launch Linux kernel ...
Thank you for the answers, that was helpful.

I think I initially misunderstood TrenchBoot, thinking that a Secure
Launch'd kernel/userspace would be the "normal" OS that would
transition to multi-user mode and be available for users and
applications.  However, on reading your response it appears that the
Secure Launch'd kernel/initramfs exists only to verify a secondary
kernel/initramfs/userspace and then kexec() into that once verified.
Finally if your schedule allows it and it is not too much to ask, it
would be greatly appreciated if some code review could be provided.
Otherwise thank you for taking the time that you have to review the
approach.
I have to admit that I'm not sure I'm the most appropriate person to
review all of the Intel TXT related assembly, but I could give it a
shot as time allows.  I would think Intel would be willing to help out
here if one were to ask nicely :)

Beyond that, and with my new understanding of how TrenchBoot is
supposed to work, I guess my only other concern is how one might
verify the integrity of the Secure Launch environment on the local
system during boot.  My apologies if I missed some details about that
in your docs, responses, etc. but is this something that TrenchBoot is
planning on addressing (or has already addressed)?

-- 
paul moore
www.paul-moore.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help