Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
MIME-Version: 1.0
References: <20220329174057.GA17778@srcf.ucam.org> <CAMj1kXE-7yPTBgQQKXRnQbdvLMv6D7=CowtQ38PdpPVa3SW-Ag@mail.gmail.com>
 <20220330071103.GA809@srcf.ucam.org> <CAMj1kXE9WrBOUG6MRQ90cMH_NvvCw_jVCar5Dsj+gkZr1AA0MQ@mail.gmail.com>
 <20220330071859.GA992@srcf.ucam.org> <CAMj1kXHfw75GphiewQzbA-swsMD3AGunyhc9HSue_xqrHt9GhQ@mail.gmail.com>
 <20220330072755.GA1169@srcf.ucam.org>
In-Reply-To: <20220330072755.GA1169@srcf.ucam.org>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Wed, 30 Mar 2022 09:39:23 +0200
Message-ID: <CAMj1kXHJxmdLie1JE=k3O4zne8tHED7g63rj42q-sL_JQUpvNw@mail.gmail.com>
Subject: Re: Linux DRTM on UEFI platforms
To:     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>,
        James Bottomley <James.Bottomley@hansenpartnership.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>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

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.

But more fundamentally, I am failing to see the distinction here
between stub code and other kernel code. Is it related to the exact
moment the secure launch event is triggered?

The way I see it, being able to marshall everything that goes on
between the stub and the secure launch kernel allows the latter to
make an informed decision about how the stub has manipulated the
global system state before triggering the secure launch event at
exitbootservices time.

But perhaps my mental model is simply too inaccurate - it would be
helpful to understand what exactly needs to be locked down, and what
aspects of the system state are of interest for the DRTM measurements.