Linux-Doc Archive on lore.kernel.org
 help / color / Atom feed
From: Matthew Garrett <mjg59@google.com>
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
Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support
Date: Thu, 26 Mar 2020 13:19:30 -0700
Message-ID: <CACdnJutT1F7YJ5KFkyuaZv=nj8GqC+mrnoAsHZfMP1ZRNUQg3Q@mail.gmail.com> (raw)
In-Reply-To: <20200326134011.c4dswiq2g7eln3qd@tomti.i.net-space.pl>

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.

  reply index

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-25 19:43 Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 01/12] x86: Secure Launch Kconfig Ross Philipson
2020-03-26 18:06   ` Daniel Kiper
2020-03-26 19:42     ` Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 02/12] x86: Secure Launch main header file Ross Philipson
2020-03-26 19:00   ` Daniel Kiper
2020-03-25 19:43 ` [RFC PATCH 03/12] x86: Add early SHA support for Secure Launch early measurements Ross Philipson
2020-03-26  3:44   ` Andy Lutomirski
2020-03-26 22:49     ` Daniel P. Smith
2020-03-25 19:43 ` [RFC PATCH 04/12] x86: Add early TPM TIS/CRB interface support for Secure Launch Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 05/12] x86: Add early TPM1.2/TPM2.0 " Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 06/12] x86: Add early general TPM " Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 07/12] x86: Secure Launch kernel early boot stub Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 08/12] x86: Secure Launch kernel late " Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 09/12] x86: Secure Launch SMP bringup support Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 10/12] x86: Secure Launch adding event log securityfs Ross Philipson
2020-03-25 20:21   ` Matthew Garrett
2020-03-25 21:43     ` Daniel P. Smith
2020-03-25 19:43 ` [RFC PATCH 11/12] kexec: Secure Launch kexec SEXIT support Ross Philipson
2020-03-25 19:43 ` [RFC PATCH 12/12] tpm: Allow locality 2 to be set when initializing the TPM for Secure Launch Ross Philipson
2020-03-25 20:29 ` [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support Matthew Garrett
2020-03-25 22:51   ` Andy Lutomirski
2020-03-26 20:50     ` Daniel P. Smith
2020-03-26 23:13       ` Andy Lutomirski
2020-05-11 19:00         ` Daniel P. Smith
2020-03-26 13:40   ` Daniel Kiper
2020-03-26 20:19     ` Matthew Garrett [this message]
2020-03-26 20:33       ` Andy Lutomirski
2020-03-26 20:40         ` Matthew Garrett
2020-03-26 20:59           ` Daniel P. Smith
2020-03-26 21:07           ` Andy Lutomirski
2020-03-26 21:28             ` Matthew Garrett
2020-03-26 22:52               ` Andy Lutomirski
2020-03-26 22:59                 ` Matthew Garrett
2020-03-26 23:04                   ` Andy Lutomirski
2020-03-27  0:01                     ` Daniel P. Smith
2020-03-26 23:50                 ` Daniel P. Smith
2020-05-11 19:00       ` Daniel P. Smith
2020-03-26 20:50   ` Daniel P. Smith
2020-03-26 20:54     ` Matthew Garrett
2020-03-26 22:37       ` Daniel P. Smith
2020-03-26 22:41         ` Matthew Garrett
2020-03-26 23:55           ` Daniel P. Smith

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACdnJutT1F7YJ5KFkyuaZv=nj8GqC+mrnoAsHZfMP1ZRNUQg3Q@mail.gmail.com' \
    --to=mjg59@google.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=daniel.kiper@oracle.com \
    --cc=dpsmith@apertussolutions.com \
    --cc=eric.snowberg@oracle.com \
    --cc=hpa@zytor.com \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=krystian.hebel@3mdeb.com \
    --cc=leif@nuviainc.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michal.zygowski@3mdeb.com \
    --cc=mingo@redhat.com \
    --cc=piotr.krol@3mdeb.com \
    --cc=ross.philipson@oracle.com \
    --cc=tglx@linutronix.de \
    --cc=trenchboot-devel@googlegroups.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Doc Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-doc/0 linux-doc/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-doc linux-doc/ https://lore.kernel.org/linux-doc \
		linux-doc@vger.kernel.org
	public-inbox-index linux-doc

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-doc


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git