From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id ECF1CC433F5 for ; Wed, 30 Mar 2022 07:39:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243876AbiC3Hl3 (ORCPT ); Wed, 30 Mar 2022 03:41:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36530 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235235AbiC3HlW (ORCPT ); Wed, 30 Mar 2022 03:41:22 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C83851AF13; Wed, 30 Mar 2022 00:39:37 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 7E6B8B81B7D; Wed, 30 Mar 2022 07:39:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C97EC34118; Wed, 30 Mar 2022 07:39:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1648625975; bh=0XeYhsl1ZxDhV4sY7GOOVxgbryVcP5F+HskgMIPxod4=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=ExC06KErHmWeEDo4Zhv8jhhzxIMG1rqWzp0/vfcmYfr8GgJgfXb0rTaznNTAdclYy k+piUt5CgH2QgNxa1be2bTf3tleGz4lc0hOvN08BW9W8xdHxqitPJYii4yGdKurXTt o0diCJUcD86JGy8q4nRLORpmkkr0i1coHwvI/ZduND1fyRqqnThtp9JBq4t1KCvp5D ykOCCxMMgx3Y+DOQWGc4iNnoofojEzIYGVOTPiOJaq2qf3SEENS475t/5amuAk3kib gYMB1JKlv2PI4q0yPeNS8sbajJMLg3WmvQfP9XhoJbDjz6l00H41Qa/e2UMu9yxjDo T3NYuemXFHnig== Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-df26ea5bfbso3687338fac.1; Wed, 30 Mar 2022 00:39:35 -0700 (PDT) X-Gm-Message-State: AOAM532IVYWfTOxQIhJgrVm5Ln7K1HrCq+tFS1W2PPfcQZmC7KVAJMtZ oPAYt6YHE0TsQyPB4uRmi6J5HKshzrzL4kPo2GA= X-Google-Smtp-Source: ABdhPJx225Afar3LspP5RUzbPIziwrBqv25u8nl0BGy9GSxxPrtSeWBL3rp23u5kP4NBabwsdgPEW2W657+hTk1C3Bw= X-Received: by 2002:a05:6870:eaa5:b0:da:b3f:2b45 with SMTP id s37-20020a056870eaa500b000da0b3f2b45mr1580495oap.228.1648625974238; Wed, 30 Mar 2022 00:39:34 -0700 (PDT) MIME-Version: 1.0 References: <20220329174057.GA17778@srcf.ucam.org> <20220330071103.GA809@srcf.ucam.org> <20220330071859.GA992@srcf.ucam.org> <20220330072755.GA1169@srcf.ucam.org> In-Reply-To: <20220330072755.GA1169@srcf.ucam.org> From: Ard Biesheuvel Date: Wed, 30 Mar 2022 09:39:23 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Linux DRTM on UEFI platforms To: Matthew Garrett Cc: Daniel Kiper , Alec Brown , Kanth Ghatraju , Ross Philipson , "dpsmith@apertussolutions.com" , "piotr.krol@3mdeb.com" , "krystian.hebel@3mdeb.com" , "persaur@gmail.com" , "Yoder, Stuart" , Andrew Cooper , "michal.zygowski@3mdeb.com" , James Bottomley , "lukasz@hawrylko.pl" , linux-efi , Linux Kernel Mailing List , The development of GNU GRUB , Kees Cook Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 30 Mar 2022 at 09:27, Matthew Garrett wrote: > > On Wed, Mar 30, 2022 at 09:23:17AM +0200, Ard Biesheuvel wrote: > > On Wed, 30 Mar 2022 at 09:19, Matthew Garrett 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.