Linux-Doc Archive on
 help / color / Atom feed
From: "Daniel P. Smith" <>
To: Andy Lutomirski <>, Matthew Garrett <>
Cc: Ross Philipson <>,
	Linux Kernel Mailing List <>,
	the arch/x86 maintainers <>,
	"open list:DOCUMENTATION" <>,
	Thomas Gleixner <>,
	Ingo Molnar <>, Borislav Petkov <>,
	"H. Peter Anvin" <>,
Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support
Date: Thu, 26 Mar 2020 16:50:43 -0400
Message-ID: <> (raw)
In-Reply-To: <>

On 3/25/20 6:51 PM, Andy Lutomirski wrote:
> On Wed, Mar 25, 2020 at 1:29 PM Matthew Garrett <> wrote:
>> On Wed, Mar 25, 2020 at 12:43 PM Ross Philipson
>> <> 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.
> I was wondering why the bootloader was involved at all.  In other
> words, could you instead hand off control to the kernel just like
> normal and have the kernel itself (in normal code, the EFI stub, or
> wherever it makes sense) do the DRTM launch all by itself?  This would
> avoid needing to patch bootloaders, to implement this specially for
> QEMU -kernel, to get the exact right buy-in from all the cloud
> vendors, etc.  It would also give you more flexibility to evolve
> exactly what configuration maps to exactly what PCRs in the future.

Partly this is driven by the fact that one of the goals for the
TrenchBoot project is about more universal/unified, cross open source
project adoption of Dynamic Launch. Another aspect is that initiating a
Dynamic Launch requires additional file(s) to be loaded, the platform to
be put into a quiescent state, and the invocation of the SENTER/SKINIT
instruction can be thought of as a soft reset of the CPU that on Intel
even results in the CPU being in a different mode (SMX) which has a
subtle change to its behavior. In the TCG Dynamic Launch design, the
component responsible for this loading, preparing, and Dynamic Launch
Instruction invocation is referred to as the Preamble and IMHO the best
time for dealing with such a disruptive behavior caused by invoking the
instruction is at the boot boundary. It also makes for a good transition
point to enable switching between kernels in control of the system
whereby the integrity will be establish by the hardware instead of the
kernel (UEFI, GRUB, Linux, etc.) that loaded it. I think what helps
address your concern is that one of the next items on the roadmap is to
extend kexec to be able to perform the Preamble. As I just mentioned,
this provides a clean way to transition for one Linux kernel that may or
may not have been started via a Dynamic Launch could relaunch itself,
launch a new Linux kernel, or even launch a non-Linux kernel that is
Dynamic Launch aware.

As for controlling which PCRs are used, the ability to control that is
actually quite limited. The CPU will always put its first measurement
into PCR 17 and then next set of measurement will differ depending on
whether you are on Intel or AMD. With Intel, the Intel provided binary
blob called the ACM has a fixed measurement policy it uses to place
measurements into PCRs 17 and 18. On AMD they left their ACM equivalent
as an exercise for the implementer (for which we have one in
development) which give us control over the measurements that it takes.
Then you have to consider the properties of the DRTM PCRs, 17-22, where
PCRs 17, 18, and 19 are the only ones that cannot be reset after the
DRTM event. Where as PCRs 20, 21, 22 can be reset by Locality 2, the
highest locality for which the kernel will be able to request/access.

I hope this helps and if you have any other questions concerns I would
be glad to answer them.

Daniel P. Smith

  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 [this message]
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
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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \

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

Linux-Doc Archive on

Archives are clonable:
	git clone --mirror 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/ \
	public-inbox-index linux-doc

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone