From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from list by lists.gnu.org with archive (Exim 4.90_1)
	id 1oLpnB-0006kv-UR
	for mharc-grub-devel@gnu.org; Wed, 10 Aug 2022 13:46:55 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:60084)
 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 1oLpn6-0006jr-LW
 for grub-devel@gnu.org; Wed, 10 Aug 2022 13:46:49 -0400
Received: from cavan.codon.org.uk ([176.126.240.207]:43630)
 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 1oLpn0-0006m3-Fu
 for grub-devel@gnu.org; Wed, 10 Aug 2022 13:46:48 -0400
Received: by cavan.codon.org.uk (Postfix, from userid 1000)
 id 815D840A8A; Wed, 10 Aug 2022 18:46:38 +0100 (BST)
Date: Wed, 10 Aug 2022 18:46:38 +0100
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Brendan Trotter <btrotter@gmail.com>
Cc: 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: <20220810174638.GA7906@srcf.ucam.org>
References: <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>
 <f09fe749-e139-db6a-b2ad-45db76da04ae@apertussolutions.com>
 <CAELHeEe5H8BNf8K22XRm3hXf=_imHBnf-MHcFYvPCXX7GYkt4w@mail.gmail.com>
 <203110bb-b70b-b4f1-9453-46136659f84c@apertussolutions.com>
 <CAELHeEe2CiTXfMf3OYu3bzc_kH=rs4qzC-4XQL12AM=Nq8Csjw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAELHeEe2CiTXfMf3OYu3bzc_kH=rs4qzC-4XQL12AM=Nq8Csjw@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_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01,
 T_SPF_HELO_TEMPERROR=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: Wed, 10 Aug 2022 17:46:49 -0000

On Wed, Aug 10, 2022 at 06:37:18PM +0930, Brendan Trotter wrote:

> [1] doesn't provide any useful information. How does a kernel know
> that the callback provided by boot loader actually measures what it's
> supposed to measure, or even does anything at all?

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.

> [1] doesn't provide any useful information. Senter and skinit don't
> provide a method for kernel to detect that (e.g.) a MiTM boot loader
> has always measured a forgery and has changed unmeasured code in a
> different way every time you boot.

Measurements are not opaque objects. If you're not able to reconstruct 
the expected measurement then you're doing it wrong.