linux-kernel - Re: [RFC PATCH 00/12] x86: Trenchboot secure late 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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 26 Mar 2020 16:50:25 -0400
From:   "Daniel P. Smith" <dpsmith@...rtussolutions.com>
To:     Matthew Garrett <mjg59@...gle.com>,
        Ross Philipson <ross.philipson@...cle.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        linux-doc@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, trenchboot-devel@...glegroups.com
Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel
 support

On 3/25/20 4:29 PM, Matthew Garrett wrote:
> On Wed, Mar 25, 2020 at 12:43 PM Ross Philipson
> <ross.philipson@...cle.com> wrote:
>> To enable the kernel to be launched by GETSEC or SKINIT, a stub must be
>> built into the setup section of the compressed kernel to handle the
>> specific state that the late launch process leaves the BSP. This is a
>> lot like the EFI stub that is found in the same area. Also this stub
>> must measure everything that is going to be used as early as possible.
>> This stub code and subsequent code must also deal with the specific
>> state that the late launch leaves the APs in.
> 
> How does this integrate with the EFI entry point? That's the expected
> entry point on most modern x86. What's calling ExitBootServices() in
> this flow, and does the secure launch have to occur after it? It'd be
> a lot easier if you could still use the firmware's TPM code rather
> than carrying yet another copy.

It is not part of the EFI entry point as we are not entering the kernel
from EFI but I will address that further in my response to Andy. The
expectation is that if you are on an UEFI platform then EBS should have
already been called. With respect to using the firmware's TPM code, one
of the purposes of a TCG Dynamic Launch is to remove the firmware from
the code being trusted in making the integrity measurement of the
kernel. I trust the firmware to initialize the hardware because I have
to and it does give a trust chain, aka the SRTM, that can attest to what
was used during that process. When the OS kernel is being started that
trust chain has become weak (or even broken). I want a new trust chain
that can provide better footing for asserting the integrity of the
kernel and this is what Dynamic Launch gives us. I would like to think I
did a fair job explaining this at LSS last fall[1][2] and would
recommend those that are curious to review the slides/watch the
presentation.

V/r,
Daniel P. Smith

[1]
https://lssna19.sched.com/event/RHb0/trenchboot-how-to-nicely-boot-system-with-intel-txt-and-amd-svm-daniel-kiper-oracle-daniel-smith-apertus-solutions
[2] https://youtu.be/DbpCU9iSi4g