Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
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>
In-Reply-To: <20220330071859.GA992@srcf.ucam.org>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Wed, 30 Mar 2022 09:23:17 +0200
Message-ID: <CAMj1kXHfw75GphiewQzbA-swsMD3AGunyhc9HSue_xqrHt9GhQ@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:19, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>
> On Wed, Mar 30, 2022 at 09:12:19AM +0200, Ard Biesheuvel wrote:
> > On Wed, 30 Mar 2022 at 09:11, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > > The EFI stub carries out a bunch of actions that have meaningful
> > > security impact, and that's material that should be measured. Having the
> > > secure launch kernel execute the stub without awareness of what it does
> > > means it would need to measure the code without measuring the state,
> > > while the goal of DRTM solutions is to measure state rather than the
> > > code.
> >
> > But how is that any different from the early kernel code?
>
> 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.

In fact, I have been experimenting with running the EFI stub
unprivileged on arm64, which would give the secure launch kernel very
tight control over what goes on between the stub entry and
ExitBootServices(). I would be happy to entertain patches that remove
any issues that complicate running the stub unprivileged for x86 or
other architectures.