From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oMCrm-0007B6-Az for mharc-grub-devel@gnu.org; Thu, 11 Aug 2022 14:25:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55558) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMCrj-0007AX-Tx for grub-devel@gnu.org; Thu, 11 Aug 2022 14:25:07 -0400 Received: from cavan.codon.org.uk ([176.126.240.207]:49218) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMCrh-0002rB-Fs for grub-devel@gnu.org; Thu, 11 Aug 2022 14:25:07 -0400 Received: by cavan.codon.org.uk (Postfix, from userid 1000) id 2E2B040A56; Thu, 11 Aug 2022 19:25:02 +0100 (BST) Date: Thu, 11 Aug 2022 19:25:02 +0100 From: Matthew Garrett To: Brendan Trotter Cc: 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: <20220811182502.GA32433@srcf.ucam.org> References: <7aab2990-9c57-2456-b08d-299ae96ac919@apertussolutions.com> <203110bb-b70b-b4f1-9453-46136659f84c@apertussolutions.com> <20220810174638.GA7906@srcf.ucam.org> 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) 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2022 18:25:08 -0000 On Thu, Aug 11, 2022 at 07:25:58PM +0930, Brendan Trotter wrote: > Hi, > > On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett wrote: > > The kernel has no way to know this - *any* code you've run before > > performing a measurement could tamper with the kernel such that it > > believes it's fine. This is just as true in DRTM as it is in SRTM. But > > you know what the expected measurements should be, so you're able to > > either seal secrets to those PCR values or rely on remote attestation. > > In this scenario the kernel has no idea what the measurement should > be, it only knows the measurement that a potentially malicious boot > loader felt like giving the kernel previously (e.g. when the kernel > was installed). Even if the kernel has an idea of what the measurement should be, it has no way to verify that what it believes to be true is true - any malicious code could simply have modified the kernel to believe that anything it asks the TPM returns the "correct" answer. > > Measurements are not opaque objects. If you're not able to reconstruct > > the expected measurement then you're doing it wrong. > > OK; so to detect if boot loader has always given kernel a bad/forged > measurement; the kernel repeats all of the steps involved in creating > the measurement itself exactly the same as the boot loader should have > (but might not have) so that kernel can compare a "known > good/trustworthy" measurement with the useless measurement that the > boot loader created for no sane reason whatsoever? No, some external agent does. Code running on the local machine can never determine whether the machine is trustworthy.