Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support

[Andy Lutomirski <luto@amacapital.net>]

> On Mar 26, 2020, at 1:19 PM, Matthew Garrett <mjg59@google.com> wrote:
> 
> On Thu, Mar 26, 2020 at 6:40 AM Daniel Kiper <daniel.kiper@oracle.com> wrote:
>>> On Wed, Mar 25, 2020 at 01:29:03PM -0700, 'Matthew Garrett' via trenchboot-devel wrote:
>>> On Wed, Mar 25, 2020 at 12:43 PM Ross Philipson
>>> <ross.philipson@oracle.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
>> 
>> It does not. We do not want and need to tie secure launch with UEFI.
> 
> I agree that it shouldn't be required, but it should be possible. We
> shouldn't add new entry points that don't integrate with the standard
> way of booting the kernel.
> 
>>> What's calling ExitBootServices() in
>> 
>> Currently it is a bootloader, the GRUB which I am working on... OK, this
>> is not perfect but if we want to call ExitBootServices() from the kernel
>> then we have to move all pre-launch code from the bootloader to the
>> kernel. Not nice because then everybody who wants to implement secure
>> launch in different kernel, hypervisor, etc. has to re-implement whole
>> pre-launch code again.
> 
> We call ExitBootServices() in the EFI stub, so this is fine as long as
> the EFI stub hands over control to the SL code. But yes, I think it's
> a requirement that it be kernel-owned code calling ExitBootServices().
> 
>>> this flow, and does the secure launch have to occur after it? It'd be
>> 
>> Yes, it does.
> 
> Ok. The firmware TPM interfaces are gone after ExitBootServices(), so
> we're going to need an additional implementation.
> 
>> I think any post-launch code in the kernel should not call anything from
>> the gap. And UEFI belongs to the gap. OK, we can potentially re-use UEFI
>> TPM code in the pre-launch phase but I am not convinced that we should
>> (I am looking at it right now). And this leads us to other question
>> which pops up here and there. How to call UEFI runtime services, e.g. to
>> modify UEFI variables, update firmware, etc., from MLE or even from the
>> OS started from MLE? In my opinion it is not safe to call anything from
>> the gap after secure launch. However, on the other hand we have to give
>> an option to change the boot order or update the firmware. So, how to
>> do that? I do not have an easy answer yet...
> 
> How does Windows manage this? Retaining access to EFI runtime services
> is necessary, and the areas in the memory map marked as runtime
> services code or data should be considered part of the TCB and
> measured - they're very much not part of the gap.

As a straw-man approach: make the rule that we never call EFI after secure launch. Instead we write out any firmware variables that we want to change on disk somewhere.  When we want to commit those changes, we reboot, commit the changes, and re-launch. Or we deactivate the kernel kexec-style, seal the image against PCRs, blow away PCRs, call EFI, relaunch, unseal the PCRs, and continue on our merry way.

I’m not sure how SMM fits in to this whole mess.

If we insist on allowing EFI calls and SMM, then we may be able to *measure* our exposure to potentially malicious firmware, but we can’t eliminate it. I personally trust OEM firmware about as far as I can throw it.