From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1oMNd6-0002cz-5H for mharc-grub-devel@gnu.org; Fri, 12 Aug 2022 01:54:44 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMNd4-0002cp-MG for grub-devel@gnu.org; Fri, 12 Aug 2022 01:54:42 -0400 Received: from irc.codon.org.uk ([2a00:1098:84:22e::2]:52302 helo=cavan.codon.org.uk) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oMNd1-0006Vu-Le for grub-devel@gnu.org; Fri, 12 Aug 2022 01:54:42 -0400 Received: by cavan.codon.org.uk (Postfix, from userid 1000) id 168AC40A77; Fri, 12 Aug 2022 06:54:37 +0100 (BST) Date: Fri, 12 Aug 2022 06:54:37 +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: <20220812055437.GA10952@srcf.ucam.org> References: <203110bb-b70b-b4f1-9453-46136659f84c@apertussolutions.com> <20220810174638.GA7906@srcf.ucam.org> <20220811182502.GA32433@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: neutral client-ip=2a00:1098:84:22e::2; envelope-from=mjg59@codon.org.uk; helo=cavan.codon.org.uk X-Spam_score_int: -5 X-Spam_score: -0.6 X-Spam_bar: / X-Spam_report: (-0.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, KHOP_HELO_FCRDNS=0.187, SPF_HELO_NEUTRAL=0.112, SPF_NEUTRAL=0.779, 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: Fri, 12 Aug 2022 05:54:42 -0000 On Fri, Aug 12, 2022 at 12:52:58PM +0930, Brendan Trotter wrote: > Hi, > > On Fri, Aug 12, 2022 at 3:55 AM Matthew Garrett wrote: > > On Thu, Aug 11, 2022 at 07:25:58PM +0930, Brendan Trotter wrote: > > > 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. > > Right. To achieve the best possible security; you'd need Secure Boot > to ensure that the kernel itself wasn't modified, and then the kernel > establishes a dynamic root of trust itself. You can't rely on Secure Boot because compromised firmware might fail to implement it, so you're back to relying on dynamic trust. > Anything involving a boot loader (e.g. Secure Boot ensure's boot > loader wasn't modified, then boot loader ensure's kernel wasn't > modified, then ....) increases the attack surface for no benefit. I honestly feel like we're talking about different things. Can you describe the attack vector you're concerned about here? > I'm not convinced an external agent can detect "bad/forged > measurement" either. E.g. if a MiTM boot loader always provided a > bad/forged measurement the external agent won't detect it (as the > measurement always matches the expected measurement), and then if the > MiTM boot loader is replaced by a good/honest boot loader the external > agent will decide that the good/honest boot loader is malicious > because its measurement doesn't match the expected bad/forged > measurement. The point of DRTM is that the platform (in the form of an authenticated code module running on the CPU, outside of the control of the OS) performs a measreument of a specific point in time. The policy it's provided with allows an external agent to identify which component of the runtime system is being measured. If an external malicious agent has been executed then the measurement will be different as a result.