From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ard Biesheuvel <ardb@kernel.org>, Matthew Garrett <mjg59@srcf.ucam.org>
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
Alec Brown <alec.r.brown@oracle.com>,
Kanth Ghatraju <kanth.ghatraju@oracle.com>,
Ross Philipson <ross.philipson@oracle.com>,
"dpsmith@apertussolutions.com" <dpsmith@apertussolutions.com>,
"piotr.krol@3mdeb.com" <piotr.krol@3mdeb.com>,
"krystian.hebel@3mdeb.com" <krystian.hebel@3mdeb.com>,
"persaur@gmail.com" <persaur@gmail.com>,
"Yoder, Stuart" <stuart.yoder@arm.com>,
Andrew Cooper <andrew.cooper3@citrix.com>,
"michal.zygowski@3mdeb.com" <michal.zygowski@3mdeb.com>,
"lukasz@hawrylko.pl" <lukasz@hawrylko.pl>,
linux-efi <linux-efi@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
The development of GNU GRUB <grub-devel@gnu.org>,
Kees Cook <keescook@chromium.org>
Subject: Re: Linux DRTM on UEFI platforms
Date: Wed, 30 Mar 2022 08:46:41 -0400 [thread overview]
Message-ID: <41521e8ecd2876327cd8dd929b32aa3b7e9daca8.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAMj1kXHJxmdLie1JE=k3O4zne8tHED7g63rj42q-sL_JQUpvNw@mail.gmail.com>
On Wed, 2022-03-30 at 09:39 +0200, Ard Biesheuvel wrote:
> On Wed, 30 Mar 2022 at 09:27, Matthew Garrett <mjg59@srcf.ucam.org>
> wrote:
> > On Wed, Mar 30, 2022 at 09:23:17AM +0200, Ard Biesheuvel wrote:
> > > On Wed, 30 Mar 2022 at 09:19, Matthew Garrett <
> > > mjg59@srcf.ucam.org> wrote:
> > > > From a conceptual perspective we've thought of the EFI stub as
> > > > being logically part of the bootloader rather than the early
> > > > kernel, and the bootloader is a point where the line is drawn.
> > > > My guy feeling is that jumping into the secure kernel
> > > > environment before EBS has been called is likely to end badly.
> > >
> > > If you jump back into the system firmware, sure.
> > >
> > > But the point I was trying to make is that you can replace that
> > > with your own minimal implementation of EFI that just exposes a
> > > memory map and some protocols and nothing else, and then the
> > > secure launch kernel would be entirely in charge of the execution
> > > environment.
> >
> > We can't just replace system firmware with an imitation of the same
> > - for instance, configuring the cold boot prevention memory
> > overwrite requires us to pass a variable through to the real
> > firmware, and that's something that we do in the stub.
> >
>
> But these are exactly the kinds of things the secure launch kernel
> wants to be made aware of, no? The secure launch kernel could just
> MITM the calls that it chooses to allow, and serve other calls
> itself.
The problem would become that the MITM firmware has to be evolved in
lockstep with the boot stub. The problem isn't really a point in time,
figure out what config the boot stub extracts from EFI now and measure
it, it's an ongoing one: given an evolving kernel and UEFI subsystem
means that over time what configuration the kernel extracts from EFI
changes, how do we make sure it's all correctly measured before secure
launch?
If the MITM doesn't support a capability a newer kernel acquires, that
MITM must fail secure launch ... which becomes a nightmare for the
user.
One possibility might be that the MITM actually does nothing at all
except record Boot Service requests and responses up to exit boot
services (EBS). We could call that record the boot configuration and
measure it, plus we could then intercept EBS, and do the DRTM secure
launch to the return point. It's conceptually similar Matthew's idea
of a callback except it won't require modification of the boot
parameters.
James
next prev parent reply other threads:[~2022-03-30 12:47 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-29 17:40 Linux DRTM on UEFI platforms Matthew Garrett
2022-03-30 7:02 ` Ard Biesheuvel
2022-03-30 7:11 ` Matthew Garrett
2022-03-30 7:12 ` Ard Biesheuvel
2022-03-30 7:18 ` Matthew Garrett
2022-03-30 7:23 ` Ard Biesheuvel
2022-03-30 7:27 ` Matthew Garrett
2022-03-30 7:39 ` Ard Biesheuvel
2022-03-30 12:46 ` James Bottomley [this message]
2022-03-31 0:35 ` Daniel P. Smith
2022-03-31 7:13 ` Ard Biesheuvel
2022-03-31 10:59 ` Heinrich Schuchardt
2022-05-19 20:57 ` Daniel P. Smith
2022-05-19 20:57 ` Daniel P. Smith
2022-06-10 16:40 ` Ard Biesheuvel
2022-07-05 18:35 ` Daniel P. Smith
2022-07-06 0:03 ` Brendan Trotter
2022-07-06 0:12 ` Matthew Garrett
2022-07-07 9:46 ` Daniel P. Smith
2022-07-08 3:36 ` Brendan Trotter
2022-07-08 4:56 ` Matthew Garrett
2022-07-22 17:23 ` Daniel P. Smith
2022-07-23 5:15 ` Brendan Trotter
2022-08-09 10:53 ` Daniel P. Smith
2022-08-10 9:07 ` Brendan Trotter
2022-08-10 17:46 ` Matthew Garrett
2022-08-11 9:55 ` Brendan Trotter
2022-08-11 11:34 ` Daniel Kiper
2022-08-11 18:25 ` Matthew Garrett
2022-08-12 3:22 ` Brendan Trotter
2022-08-12 5:54 ` Matthew Garrett
2022-08-05 12:53 ` Ard Biesheuvel
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=41521e8ecd2876327cd8dd929b32aa3b7e9daca8.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=alec.r.brown@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=ardb@kernel.org \
--cc=daniel.kiper@oracle.com \
--cc=dpsmith@apertussolutions.com \
--cc=grub-devel@gnu.org \
--cc=kanth.ghatraju@oracle.com \
--cc=keescook@chromium.org \
--cc=krystian.hebel@3mdeb.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lukasz@hawrylko.pl \
--cc=michal.zygowski@3mdeb.com \
--cc=mjg59@srcf.ucam.org \
--cc=persaur@gmail.com \
--cc=piotr.krol@3mdeb.com \
--cc=ross.philipson@oracle.com \
--cc=stuart.yoder@arm.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.