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 15:41:29 -0700
From:   Matthew Garrett <mjg59@...gle.com>
To:     "Daniel P. Smith" <dpsmith@...rtussolutions.com>
Cc:     Ross Philipson <ross.philipson@...cle.com>,
        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 Thu, Mar 26, 2020 at 3:37 PM Daniel P. Smith
<dpsmith@...rtussolutions.com> wrote:
> On 3/26/20 4:54 PM, Matthew Garrett wrote:
> > PCs depend on the availability of EFI runtime services - it's not
> > possible to just assert that they're untrusted and so unsupported. The
> > TPM code is part of boot services which (based on your design) are
> > unavailable at this point, so I agree that you need your own
> > implementation.
> >
>
> I appreciate this has been a heated area of debate, but with all due
> respect that might be a slight over statement w.r.t. dependency on
> runtime services and not what I was saying about the trustworthiness of
> UEFI. If I have a UEFI platform, I trust EFI to boot the system but that
> does not mean I have to trust it to measure my OS kernel or manage the
> running system. Secure Launch provides a means to start a measurement
> trust chain starting with CPU taking the first measurement and then I
> can do things like disabling runtime services in the kernel or do crazy
> things like using the dynamic launch to switch to a minimal temporary
> kernel that can do high trust operations such as interfacing with
> entities outside your trust boundary, e.g. runtime services.

I understand. However, it is *necessary* for EFI runtime services to
be available somehow, and this design needs to make that possible.
Either EFI runtime services need to be considered part of the TCB, or
we need a mechanism to re-verify the state of the system after making
an EFI call (such as Andy's suggestion).

> Please understand I really do not want my own implementation. I tried to
> see if we could just #include in the minimal needed parts from the
> in-tree TPM driver but could not find a clean way to do so. Perhaps
> there might be a future opportunity to collaborate with the TPM driver
> maintainers to refactor in a way that we can just reuse instead of
> reimplement.

I think it's reasonable to assert that boot services can't be part of
the TCB in this case, and as a result you're justified in not using
the firmware's TPM implementation. However, we still need a solution
for access to runtime services.