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:   Tue, 30 Nov 2021 20:06:49 -0500
From:   Paul Moore <paul@...l-moore.com>
To:     Ross Philipson <ross.philipson@...cle.com>,
        trenchboot-devel@...glegroups.com
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        iommu@...ts.linux-foundation.org, linux-integrity@...r.kernel.org,
        linux-doc@...r.kernel.org, dpsmith@...rtussolutions.com,
        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 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) ...

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

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?

>  - SL stub fixes up the world on the BSP
>  - For TXT, SL stub wakes the APs, fixes up their worlds
>  - For TXT, APs are left halted waiting for an NMI to wake them
>  - SL stub jumps to startup_32
>  - SL main locates the TPM event log and writes the measurements of
>    configuration and module information into it.

Since the stub+kernel image are combined it looks like the kernel
measurement comes from the ACM via the MLE measurement into PCR 18,
while the stub generated measurements are extended into PCR 19 or 20
depending on the configuration, yes?

I realize that moving the TXT code into the kernel makes this
difficult (not possible?), but one of the things that was nice about
the tboot based approach (dynamic, early launch) was that it could be
extended to do different types of measurements, e.g. a signing
authority measurement similar to UEFI Secure Boot and PCR 7.  If that
is possible, I think it is something worth including in the design,
even if it isn't initially implemented.  The only thing that
immediately comes to mind would be a section/region based approach
similar to systemd-boot/gummiboot where the (signed) kernel is kept in
a well known region and verified/measured by the stub prior to jumping
into its start point.

>  - Kernel boot proceeds normally from this point.
>  - During early setup, slaunch_setup() runs to finish some validation
>    and setup tasks.
>  - The SMP bringup code is modified to wake the waiting APs. APs vector
>    to rmpiggy and start up normally from that point.
>  - SL platform module is registered as a late initcall module. It reads
>    the TPM event log and extends the measurements taken into the TPM PCRs.

I'm sure there is some issue with passing data across boundaries, but
is there any reason why the TPM event log needs to be updated
out-of-sync with the TPM PCRs?  Is is possible to pass the
measurements to the SL platform module which would both extend the
PCRs and update the TPM event log at the same time?

>  - SL platform module initializes the securityfs interface to allow
>    asccess to the TPM event log and TXT public registers.
>  - Kernel boot finishes booting normally
>  - SEXIT support to leave SMX mode is present on the kexec path and
>    the various reboot paths (poweroff, reset, halt).

It doesn't look like it's currently implemented, but it looks like
eventually you plan to support doing a new DRTM measurement on kexec,
is that correct?  I'm sure that is something a *lot* of people
(including myself) would like to see happen.

-- 
paul moore
www.paul-moore.com