linux-kernel - Re: Linux DRTM on UEFI platforms

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 11 Aug 2022 13:34:56 +0200
From:   Daniel Kiper <daniel.kiper@...cle.com>
To:     Brendan Trotter <btrotter@...il.com>
Cc:     Matthew Garrett <mjg59@...f.ucam.org>,
        The development of GNU GRUB <grub-devel@....org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Alec Brown <alec.r.brown@...cle.com>,
        Kanth Ghatraju <kanth.ghatraju@...cle.com>,
        Ross Philipson <ross.philipson@...cle.com>,
        "piotr.krol@...eb.com" <piotr.krol@...eb.com>,
        "krystian.hebel@...eb.com" <krystian.hebel@...eb.com>,
        "persaur@...il.com" <persaur@...il.com>,
        "Yoder, Stuart" <stuart.yoder@....com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        "michal.zygowski@...eb.com" <michal.zygowski@...eb.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        "lukasz@...rylko.pl" <lukasz@...rylko.pl>,
        linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
        James Morris <jmorris@...ei.org>, dpsmith@...rtussolutions.com
Subject: Re: Linux DRTM on UEFI platforms

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 <mjg59@...f.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?

Could you tell us where exactly boot loader creates measurements for the DRTM?

Daniel