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 66392C433EF for ; Fri, 8 Jul 2022 04:56:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237379AbiGHE4q (ORCPT ); Fri, 8 Jul 2022 00:56:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56636 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236876AbiGHE4o (ORCPT ); Fri, 8 Jul 2022 00:56:44 -0400 Received: from cavan.codon.org.uk (irc.codon.org.uk [IPv6:2a00:1098:84:22e::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 084E576E96; Thu, 7 Jul 2022 21:56:42 -0700 (PDT) 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 To: Brendan Trotter Cc: "Daniel P. Smith" , The development of GNU GRUB , Ard Biesheuvel , Daniel Kiper , Alec Brown , Kanth Ghatraju , Ross Philipson , "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@vger.kernel.org, linux-kernel@vger.kernel.org, James Morris Subject: Re: Linux DRTM on UEFI platforms Message-ID: <20220708045638.GA27939@srcf.ucam.org> References: <20220329174057.GA17778@srcf.ucam.org> <7aab2990-9c57-2456-b08d-299ae96ac919@apertussolutions.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.