From: Matthew Garrett <firstname.lastname@example.org> To: "Daniel P. Smith" <email@example.com> Cc: Ross Philipson <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, "the arch/x86 maintainers" <firstname.lastname@example.org>, email@example.com, Thomas Gleixner <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, Borislav Petkov <firstname.lastname@example.org>, "H. Peter Anvin" <email@example.com>, firstname.lastname@example.org Subject: Re: [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support Date: Thu, 26 Mar 2020 15:41:29 -0700 Message-ID: <CACdnJuvxSaF96PkCiDp5u+599+bU5SnXRgLyWetaOKa0+1UqAg@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On Thu, Mar 26, 2020 at 3:37 PM Daniel P. Smith <firstname.lastname@example.org> wrote: > On 3/26/20 4:54 PM, Matthew Garrett wrote: > > PCs depend on the availability of EFI runtime services - it's not > > possible to just assert that they're untrusted and so unsupported. The > > TPM code is part of boot services which (based on your design) are > > unavailable at this point, so I agree that you need your own > > implementation. > > > > I appreciate this has been a heated area of debate, but with all due > respect that might be a slight over statement w.r.t. dependency on > runtime services and not what I was saying about the trustworthiness of > UEFI. If I have a UEFI platform, I trust EFI to boot the system but that > does not mean I have to trust it to measure my OS kernel or manage the > running system. Secure Launch provides a means to start a measurement > trust chain starting with CPU taking the first measurement and then I > can do things like disabling runtime services in the kernel or do crazy > things like using the dynamic launch to switch to a minimal temporary > kernel that can do high trust operations such as interfacing with > entities outside your trust boundary, e.g. runtime services. I understand. However, it is *necessary* for EFI runtime services to be available somehow, and this design needs to make that possible. Either EFI runtime services need to be considered part of the TCB, or we need a mechanism to re-verify the state of the system after making an EFI call (such as Andy's suggestion). > Please understand I really do not want my own implementation. I tried to > see if we could just #include in the minimal needed parts from the > in-tree TPM driver but could not find a clean way to do so. Perhaps > there might be a future opportunity to collaborate with the TPM driver > maintainers to refactor in a way that we can just reuse instead of > reimplement. I think it's reasonable to assert that boot services can't be part of the TCB in this case, and as a result you're justified in not using the firmware's TPM implementation. However, we still need a solution for access to runtime services.
next prev 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 2020-03-26 20:54 ` Matthew Garrett 2020-03-26 22:37 ` Daniel P. Smith 2020-03-26 22:41 ` Matthew Garrett [this message] 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=CACdnJuvxSaF96PkCiDp5u+599+bU5SnXRgLyWetaOKa0+1UqAg@mail.gmail.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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 \ firstname.lastname@example.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