From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from list by lists.gnu.org with archive (Exim 4.90_1)
	id 1o9g2o-0001Nj-Ka
	for mharc-grub-devel@gnu.org; Fri, 08 Jul 2022 00:56:46 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:41066)
 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 1o9g2m-0001NY-MR
 for grub-devel@gnu.org; Fri, 08 Jul 2022 00:56:44 -0400
Received: from cavan.codon.org.uk ([176.126.240.207]:40520)
 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 1o9g2k-0005i2-4X
 for grub-devel@gnu.org; Fri, 08 Jul 2022 00:56:44 -0400
Received: by cavan.codon.org.uk (Postfix, from userid 1000)
 id 3424340A61; Fri,  8 Jul 2022 05:56:38 +0100 (BST)
Date: Fri, 8 Jul 2022 05:56:38 +0100
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Brendan Trotter <btrotter@gmail.com>
Cc: "Daniel P. Smith" <dpsmith@apertussolutions.com>,
 The development of GNU GRUB <grub-devel@gnu.org>,
 Ard Biesheuvel <ardb@kernel.org>, 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>,
 "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@vger.kernel.org, linux-kernel@vger.kernel.org,
 James Morris <jmorris@namei.org>
Subject: Re: Linux DRTM on UEFI platforms
Message-ID: <20220708045638.GA27939@srcf.ucam.org>
References: <20220329174057.GA17778@srcf.ucam.org>
 <f9622b47-c45f-8c91-cb85-e5db7fd541cf@apertussolutions.com>
 <CAMj1kXEUT8BK_akqjF1Wx0JkLniFyV_h9s1TfQnPqfxCHsKfWw@mail.gmail.com>
 <7aab2990-9c57-2456-b08d-299ae96ac919@apertussolutions.com>
 <CAELHeEfZ-feZnexp7Gx3VAJPerENcoO1Uccbe3xxUX95jvLUdA@mail.gmail.com>
 <b1e7b545-8e66-5dc0-ff5a-9f69d1751a5f@apertussolutions.com>
 <CAELHeEcEN=4YrPJROvzHoOiqqe5Bk0f8pDCZDnQ6aS=2LdwNow@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAELHeEcEN=4YrPJROvzHoOiqqe5Bk0f8pDCZDnQ6aS=2LdwNow@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: Fri, 08 Jul 2022 04:56:44 -0000

On Fri, Jul 08, 2022 at 01:06:19PM +0930, Brendan Trotter wrote:

> This leaves me wondering what your true motivation is. Are you trying
> to benefit GRUB/Trenchboot (at the expense of security, end-user
> convenience, distro installer hassle, etc); or trying to manufacture
> scope for future man-in-the middle attacks (by promoting a solution
> that requires something between firmware and kernel)?

The described mechanism doesn't require trusting the code that's in the 
middle - if the state is perturbed by this code, the measurements will 
be different, and the system will be untrusted. I agree that this 
implementation is more complicated than just leaving it all up to the 
kernel, but I'm having a *lot* of trouble seeing how this has any impact 
on its security. Jumping immediately to impugning the motivation of the 
people involved is entirely inappropriate.