From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from list by lists.gnu.org with archive (Exim 4.90_1)
	id 1nZSkM-00076I-3j
	for mharc-grub-devel@gnu.org; Wed, 30 Mar 2022 03:28:02 -0400
Received: from eggs.gnu.org ([209.51.188.92]:59672)
 by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <mjg59@codon.org.uk>)
 id 1nZSkI-000769-SK
 for grub-devel@gnu.org; Wed, 30 Mar 2022 03:27:59 -0400
Received: from cavan.codon.org.uk ([176.126.240.207]:59536)
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <mjg59@codon.org.uk>)
 id 1nZSkH-00070C-4w
 for grub-devel@gnu.org; Wed, 30 Mar 2022 03:27:58 -0400
Received: by cavan.codon.org.uk (Postfix, from userid 1000)
 id 4449D40A71; Wed, 30 Mar 2022 08:27:55 +0100 (BST)
Date: Wed, 30 Mar 2022 08:27:55 +0100
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Ard Biesheuvel <ardb@kernel.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>
Subject: Re: Linux DRTM on UEFI platforms
Message-ID: <20220330072755.GA1169@srcf.ucam.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMj1kXHfw75GphiewQzbA-swsMD3AGunyhc9HSue_xqrHt9GhQ@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Received-SPF: pass client-ip=176.126.240.207; envelope-from=mjg59@codon.org.uk;
 helo=cavan.codon.org.uk
X-Spam_score_int: -16
X-Spam_score: -1.7
X-Spam_bar: -
X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9,
 HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no
X-Spam_action: no action
X-BeenThere: grub-devel@gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: The development of GNU GRUB <grub-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/grub-devel>,
 <mailto:grub-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <https://lists.gnu.org/archive/html/grub-devel>
List-Post: <mailto:grub-devel@gnu.org>
List-Help: <mailto:grub-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/grub-devel>,
 <mailto:grub-devel-request@gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2022 07:27:59 -0000

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.