From: Matthew Garrett <mjg59@google.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
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:40:42 -0700 [thread overview]
Message-ID: <CACdnJusd7m-c0zLmAjSq9Sb9HxyCkhyyp5W=4FMdysgu7_g=Sw@mail.gmail.com> (raw)
In-Reply-To: <FE871C2B-15BB-4089-A912-40F2E9FE680B@amacapital.net>
On Thu, Mar 26, 2020 at 1:33 PM Andy Lutomirski <luto@amacapital.net> wrote:
> As a straw-man approach: make the rule that we never call EFI after secure launch. Instead we write out any firmware variables that we want to change on disk somewhere. When we want to commit those changes, we reboot, commit the changes, and re-launch. Or we deactivate the kernel kexec-style, seal the image against PCRs, blow away PCRs, call EFI, relaunch, unseal the PCRs, and continue on our merry way.
That breaks the memory overwrite protection code, where a variable is
set at boot and cleared on a controlled reboot. We'd also need to read
every variable and pass those values to the kernel in some way so the
read interfaces still work. Some platforms may also expect to be able
to use the EFI reboot call. As for the second approach - how would we
verify that the EFI code hadn't modified any user pages? Those
wouldn't be measured during the second secure launch. If we're calling
the code at runtime then I think we need to assert that it's trusted.
> I’m not sure how SMM fits in to this whole mess.
SMM's basically an unsolved problem, which makes the whole DRTM
approach somewhat questionable unless you include the whole firmware
in the TCB, which is kind of what we're trying to get away from.
> If we insist on allowing EFI calls and SMM, then we may be able to *measure* our exposure to potentially malicious firmware, but we can’t eliminate it. I personally trust OEM firmware about as far as I can throw it.
next prev parent reply other threads:[~2020-03-26 20:40 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 19:43 [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support 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 [this message]
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='CACdnJusd7m-c0zLmAjSq9Sb9HxyCkhyyp5W=4FMdysgu7_g=Sw@mail.gmail.com' \
--to=mjg59@google.com \
--cc=James.Bottomley@hansenpartnership.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=krystian.hebel@3mdeb.com \
--cc=leif@nuviainc.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).