lkml.org 
[lkml]   [2020]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support
On Thu, Mar 26, 2020 at 1:50 PM Daniel P. Smith
<dpsmith@apertussolutions.com> wrote:
> 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.

Ok. In that case should the EFI boot stub optionally be calling this
instead of startup_32?

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

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.

\
 
 \ /
  Last update: 2020-03-26 21:54    [W:1.488 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site