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

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 21 Jan 2022 16:39:51 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     "Daniel P. Smith" <dpsmith@...rtussolutions.com>
Cc:     Ross Philipson <ross.philipson@...cle.com>,
        trenchboot-devel@...glegroups.com, linux-kernel@...r.kernel.org,
        x86@...nel.org, iommu@...ts.linux-foundation.org,
        linux-integrity@...r.kernel.org, linux-doc@...r.kernel.org,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, hpa@...or.com,
        luto@...capital.net, kanth.ghatraju@...cle.com
Subject: Re: [PATCH v4 00/14] x86: Trenchboot secure dynamic launch Linux
 kernel support

On Mon, Dec 6, 2021 at 3:56 PM Paul Moore <paul@...l-moore.com> wrote:
> On Thu, Dec 2, 2021 at 11:11 AM Daniel P. Smith
> <dpsmith@...rtussolutions.com> wrote:
> > Hi Paul!
>
> /me waves
>
> > On 11/30/21 8:06 PM, Paul Moore wrote:
> > > On Fri, Aug 27, 2021 at 9:20 AM Ross Philipson
> > > <ross.philipson@...cle.com> wrote:
> > >>
> > >> 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.
> >
> > >> 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.
> >
> > > 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)?

I wanted to follow-up on this thread just in case this last question
was lost ...

-- 
paul moore
paul-moore.com