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;
Date:   Thu, 26 Mar 2020 14:40:11 +0100
From:   Daniel Kiper <daniel.kiper@oracle.com>
To:     Matthew Garrett <mjg59@google.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, ardb@kernel.org,
        leif@nuviainc.com, eric.snowberg@oracle.com, piotr.krol@3mdeb.com,
        krystian.hebel@3mdeb.com, michal.zygowski@3mdeb.com,
        james.bottomley@hansenpartnership.com, andrew.cooper3@citrix.com
Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux
 kernel support
Message-ID: <20200326134011.c4dswiq2g7eln3qd@tomti.i.net-space.pl>
References: <20200325194317.526492-1-ross.philipson@oracle.com>
 <CACdnJut56WuqO=uLff0qy1Jp=C6f_sRxLpRBsrzb6byBsFYdCg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CACdnJut56WuqO=uLff0qy1Jp=C6f_sRxLpRBsrzb6byBsFYdCg@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hey,

CC-in Ard, Leif, Eric, Piotr, Krystian, Michał, James and Andrew...

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.

> entry point on most modern x86.

Yeah, most but not all...

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

> this flow, and does the secure launch have to occur after it? It'd be

Yes, it does.

> a lot easier if you could still use the firmware's TPM code rather
> than carrying yet another copy.

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

Daniel