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 405A5C19F2A for ; Thu, 11 Aug 2022 09:56:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234534AbiHKJ4P (ORCPT ); Thu, 11 Aug 2022 05:56:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229540AbiHKJ4M (ORCPT ); Thu, 11 Aug 2022 05:56:12 -0400 Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F40937AC26; Thu, 11 Aug 2022 02:56:10 -0700 (PDT) Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-32194238c77so167748797b3.4; Thu, 11 Aug 2022 02:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=fwQUcv5ujbxHFhmwZIXEpylzN9K6eYzKvdzq8gW460k=; b=W2JCmFyw36TPiiYlXpt8XIMhf4jL8fBeavxF3RVQ4MO0ioDG9T36XnEIZcELI2I3Ez cAMWu4kgNZhbqn9DOfqbJROWucC2nnQZawxNo1iWeS2j9sZWn/QKU0WTACStWXgwDH02 4EKq3aDoivjGqql07n3S1Th2IVf93gvjIMmQ2iGFW8sjEQrIw/G7yvyQylYiOjEDkiNz bEdqQeuexai4xwvy6VU/OUNzQ5EEqVd8+tWTZsROrAN2WlmBPgcEH8nwoTFqnQkwDiZa tXdy19QKEH2LsapBp3HjN7GM/2VRZrP2YfwbwqNw8aLcKjrdctgs3AnXc9AAnJgm7h8j KC6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=fwQUcv5ujbxHFhmwZIXEpylzN9K6eYzKvdzq8gW460k=; b=yrxHWWutJSgHa66hLGJapsq0IVv/sbWqUob1jTIAVYArP79zG9fY0wkjDGbFvZvFs0 HGWKKWrZsNWVYoojfEKpqTcNUygnKYVhEX1xfAOqEYDcdedeM8UMVwlxvDZpqwEqiCOB mitHTLkA3rEx+aQSx7KLHMxYDIAE1p4aUV8lP5+PSwKzWndcHd+pW24jKl3V7WbbYeIR 8cG/3pRfxN8dj8BwPMkxHUPDIDqllG7DQwr7ei6wH652jblenN+2LkO/mIyo94BCSLJ8 7H0amoGsBNbVgMXur82P3mZInqF+v5DQ+QOgGYEFrEMTpdbavVKgwVoQCbkq/JlPC7UE o1Yg== X-Gm-Message-State: ACgBeo3TOHu2uWTVblsV/NE37p5P+RP7v6P3PDKZHlGLMIueqsxrJ3gZ 53IR6S012wMVwifYRmYggQfvbd50JvT++WUlowU= X-Google-Smtp-Source: AA6agR5/WapTssfcQ/DA4O1gE5u+PT2nJab9miAW7BuViSfiBauMIkLdsipQpxhXUp0NVgxB2l+QT0VGV90rNz5y0L0= X-Received: by 2002:a0d:e252:0:b0:322:eca5:eaf3 with SMTP id l79-20020a0de252000000b00322eca5eaf3mr33153433ywe.219.1660211770246; Thu, 11 Aug 2022 02:56:10 -0700 (PDT) MIME-Version: 1.0 References: <7aab2990-9c57-2456-b08d-299ae96ac919@apertussolutions.com> <203110bb-b70b-b4f1-9453-46136659f84c@apertussolutions.com> <20220810174638.GA7906@srcf.ucam.org> In-Reply-To: <20220810174638.GA7906@srcf.ucam.org> From: Brendan Trotter Date: Thu, 11 Aug 2022 19:25:58 +0930 Message-ID: Subject: Re: Linux DRTM on UEFI platforms To: Matthew Garrett 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 Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett wrote: > 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. 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). > > [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. 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? - Brendan