Message-ID: <d72b87f4-4e71-0b32-7faf-35f910ea76a4@apertussolutions.com>
Date:   Mon, 11 May 2020 15:00:11 -0400
From:   "Daniel P. Smith" <dpsmith@...rtussolutions.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Matthew Garrett <mjg59@...gle.com>,
        Ross Philipson <ross.philipson@...cle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        "open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, trenchboot-devel@...glegroups.com
Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel
 support

On 3/26/20 7:13 PM, Andy Lutomirski wrote:
> 
> Hmm.  I don't have any real objection to the kernel supporting this
> type of secure launch, but I do have some more questions first.

Coming back through the thread to ensure all questions have been
responded before a submission patch set is sent.

> One of the problems with the old tboot code and the general state of
> dynamic-root-of-trust is that it's an incredible pain in the neck to
> even test.  I think it would be helpful if I could build a kernel that
> supported secure launch (Intel or AMD) and just run the thing.  I
> realize that you're planning to integrate this into GRUB, etc, but it
> might be nice if even existing GRUB and EFI shell can do this.  How
> hard would it be to make the kernel support a mode where whatever
> blobs are required are in the initrd or built in like firmware and
> where I could set a command line argument like secure_launch=on and
> have the kernel secure launch itself?
> 
> Are you planning on supporting a mode where kernel A kexecs to kernel
> B, kernel B is secure launched, and then kernel B resumes kernel A and
> re-launches it?  If so, would it work better if the measured state of
> the kernel were the *uncompressed* text or even the uncompressed and
> alternative-ified text?  Or is the idea that the secure launch entry
> will figure out that it's actually a resume and not a fresh boot and
> behave accordingly?

A primary purpose of the TrenchBoot project is to make using DRTM
seamless for people, e.g. a few config settings and it just works(tm).
To achieve what you are proposing, the kernel would have to know how to
do both the DL preamble (pre-launch in tboot) and DL entry (post-launch
in tboot). The short answer is we are working towards that capability.
First is the ability to handle the DL entry, which is SecureLaunch. For
now we are clearing the SECRETS bit and doing the SEXIT leaf on kexec
and S5 to minimize the risk of bricking your system with TXT. Later the
DL preamble can be added to kexec such that the user space can
coordinate a DRTM launch. Not sure if this is exactly what you are
envisioning but albeit at least a close approximation.


> What's the situation like in a VM?  Can I run the secure launch entry
> in a VM somehow?  Can I actually initiate the dynamic launch from the
> VM?

A DL entails calling a CPU instruction which take over full control of
the system. If a hypervisor blindly allowed a VM to directly call the
op, it would end up with full control of the system outside of the
hypervisor. With that said, An approach on the roadmap for TrenchBoot is
how a hypervisor and a VM might coordinate the use of a DL to establish
a new measurement chain consisting of runtime inspection of the
hypervisor which in-turn has a means to establish the integrity of the VM.

V/r,
DPS

Powered by blists - more mailing lists