Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200325194317.526492-1-ross.philipson@oracle.com>
 <CACdnJut56WuqO=uLff0qy1Jp=C6f_sRxLpRBsrzb6byBsFYdCg@mail.gmail.com> <20200326134011.c4dswiq2g7eln3qd@tomti.i.net-space.pl>
In-Reply-To: <20200326134011.c4dswiq2g7eln3qd@tomti.i.net-space.pl>
From:   Matthew Garrett <mjg59@google.com>
Date:   Thu, 26 Mar 2020 13:19:30 -0700
Message-ID: <CACdnJutT1F7YJ5KFkyuaZv=nj8GqC+mrnoAsHZfMP1ZRNUQg3Q@mail.gmail.com>
Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support
To:     Daniel Kiper <daniel.kiper@oracle.com>
Cc:     Ross Philipson <ross.philipson@oracle.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "the arch/x86 maintainers" <x86@kernel.org>,
        linux-doc@vger.kernel.org, dpsmith@apertussolutions.com,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>,
        trenchboot-devel@googlegroups.com,
        Ard Biesheuvel <ardb@kernel.org>, leif@nuviainc.com,
        eric.snowberg@oracle.com, piotr.krol@3mdeb.com,
        krystian.hebel@3mdeb.com, michal.zygowski@3mdeb.com,
        James Bottomley <james.bottomley@hansenpartnership.com>,
        andrew.cooper3@citrix.com
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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.