On 3/26/20 6:41 PM, Matthew Garrett wrote: > On Thu, Mar 26, 2020 at 3:37 PM Daniel P. Smith > <dpsmith@xxxxxxxxxxxxxxxxxxxx> 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. >
