Linux-Doc Archive on lore.kernel.org
 help / color / Atom feed
From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
To: Matthew Garrett <mjg59@google.com>,
	Ross Philipson <ross.philipson@oracle.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	the arch/x86 maintainers <x86@kernel.org>,
	linux-doc@vger.kernel.org, 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
Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support
Date: Thu, 26 Mar 2020 16:50:25 -0400
Message-ID: <bacbc25a-c724-d2fd-40bd-065799cd6195@apertussolutions.com> (raw)
In-Reply-To: <CACdnJut56WuqO=uLff0qy1Jp=C6f_sRxLpRBsrzb6byBsFYdCg@mail.gmail.com>

On 3/25/20 4:29 PM, Matthew Garrett 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
> entry point on most modern x86. What's calling ExitBootServices() in
> this flow, and does the secure launch have to occur after it? It'd be
> a lot easier if you could still use the firmware's TPM code rather
> than carrying yet another copy.


It is not part of the EFI entry point as we are not entering the kernel
from EFI but I will address that further in my response to Andy. The
expectation is that if you are on an UEFI platform then EBS should have
already been called. With respect to using the firmware's TPM code, one
of the purposes of a TCG Dynamic Launch is to remove the firmware from
the code being trusted in making the integrity measurement of the
kernel. I trust the firmware to initialize the hardware because I have
to and it does give a trust chain, aka the SRTM, that can attest to what
was used during that process. When the OS kernel is being started that
trust chain has become weak (or even broken). I want a new trust chain
that can provide better footing for asserting the integrity of the
kernel and this is what Dynamic Launch gives us. I would like to think I
did a fair job explaining this at LSS last fall[1][2] and would
recommend those that are curious to review the slides/watch the
presentation.

V/r,
Daniel P. Smith

[1]
https://lssna19.sched.com/event/RHb0/trenchboot-how-to-nicely-boot-system-with-intel-txt-and-amd-svm-daniel-kiper-oracle-daniel-smith-apertus-solutions
[2] https://youtu.be/DbpCU9iSi4g



  parent 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
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 [this message]
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=bacbc25a-c724-d2fd-40bd-065799cd6195@apertussolutions.com \
    --to=dpsmith@apertussolutions.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=mjg59@google.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