[lkml]   [2020]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support
On 3/26/20 6:41 PM, Matthew Garrett wrote:
> On Thu, Mar 26, 2020 at 3:37 PM Daniel P. Smith
> <> 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).

Yes if you are on UEFI you will eventually need to deal with RS during
the system's lifetime, unless you don't want to patch your firmware
which I won't comment on what kind of idea that is. And yes I have been
chatting with a few people in the LinuxBoot community about re-verifying
the RS. The answer seemed to be that it might be possible but it doesn't
look like it will be trivial.

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

 \ /
  Last update: 2020-03-27 00:56    [W:0.052 / U:3.696 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site