All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brendan Trotter <btrotter@gmail.com>
To: Matthew Garrett <mjg59@srcf.ucam.org>
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
Date: Thu, 11 Aug 2022 19:25:58 +0930	[thread overview]
Message-ID: <CAELHeEdNgYCh_kQwWpEc4aXw-YL-KGrAeDCL-VaG3ChFs6LNVw@mail.gmail.com> (raw)
In-Reply-To: <20220810174638.GA7906@srcf.ucam.org>

Hi,

On Thu, Aug 11, 2022 at 3:16 AM Matthew Garrett <mjg59@srcf.ucam.org> 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

  reply	other threads:[~2022-08-11  9:56 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-29 17:40 Linux DRTM on UEFI platforms Matthew Garrett
2022-03-30  7:02 ` Ard Biesheuvel
2022-03-30  7:11   ` Matthew Garrett
2022-03-30  7:12     ` Ard Biesheuvel
2022-03-30  7:18       ` Matthew Garrett
2022-03-30  7:23         ` Ard Biesheuvel
2022-03-30  7:27           ` Matthew Garrett
2022-03-30  7:39             ` Ard Biesheuvel
2022-03-30 12:46               ` James Bottomley
2022-03-31  0:35   ` Daniel P. Smith
2022-03-31  7:13     ` Ard Biesheuvel
2022-03-31 10:59       ` Heinrich Schuchardt
2022-05-19 20:57       ` Daniel P. Smith
2022-05-19 20:57 ` Daniel P. Smith
2022-06-10 16:40   ` Ard Biesheuvel
2022-07-05 18:35     ` Daniel P. Smith
2022-07-06  0:03       ` Brendan Trotter
2022-07-06  0:12         ` Matthew Garrett
2022-07-07  9:46         ` Daniel P. Smith
2022-07-08  3:36           ` Brendan Trotter
2022-07-08  4:56             ` Matthew Garrett
2022-07-22 17:23             ` Daniel P. Smith
2022-07-23  5:15               ` Brendan Trotter
2022-08-09 10:53                 ` Daniel P. Smith
2022-08-10  9:07                   ` Brendan Trotter
2022-08-10 17:46                     ` Matthew Garrett
2022-08-11  9:55                       ` Brendan Trotter [this message]
2022-08-11 11:34                         ` Daniel Kiper
2022-08-11 18:25                         ` Matthew Garrett
2022-08-12  3:22                           ` Brendan Trotter
2022-08-12  5:54                             ` Matthew Garrett
2022-08-05 12:53       ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAELHeEdNgYCh_kQwWpEc4aXw-YL-KGrAeDCL-VaG3ChFs6LNVw@mail.gmail.com \
    --to=btrotter@gmail.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=alec.r.brown@oracle.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ardb@kernel.org \
    --cc=daniel.kiper@oracle.com \
    --cc=grub-devel@gnu.org \
    --cc=jmorris@namei.org \
    --cc=kanth.ghatraju@oracle.com \
    --cc=krystian.hebel@3mdeb.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukasz@hawrylko.pl \
    --cc=michal.zygowski@3mdeb.com \
    --cc=mjg59@srcf.ucam.org \
    --cc=persaur@gmail.com \
    --cc=piotr.krol@3mdeb.com \
    --cc=ross.philipson@oracle.com \
    --cc=stuart.yoder@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.