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]

Message-ID: <CAMj1kXE9WrBOUG6MRQ90cMH_NvvCw_jVCar5Dsj+gkZr1AA0MQ@mail.gmail.com>
Date:   Wed, 30 Mar 2022 09:12:19 +0200
From:   Ard Biesheuvel <ardb@...nel.org>
To:     Matthew Garrett <mjg59@...f.ucam.org>
Cc:     Daniel Kiper <daniel.kiper@...cle.com>,
        Alec Brown <alec.r.brown@...cle.com>,
        Kanth Ghatraju <kanth.ghatraju@...cle.com>,
        Ross Philipson <ross.philipson@...cle.com>,
        "dpsmith@...rtussolutions.com" <dpsmith@...rtussolutions.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 <linux-efi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        The development of GNU GRUB <grub-devel@....org>,
        Kees Cook <keescook@...omium.org>
Subject: Re: Linux DRTM on UEFI platforms

On Wed, 30 Mar 2022 at 09:11, Matthew Garrett <mjg59@...f.ucam.org> wrote:
>
> On Wed, Mar 30, 2022 at 09:02:18AM +0200, Ard Biesheuvel wrote:
>
> > Wouldn't it be better for the secure launch kernel to boot the EFI
> > entrypoint directly? As it happens, I just completed a PoC last week
> > for a minimal implementation of EFI (in Rust) that only carries the
> > pieces that the EFI stub needs to boot Linux. It is currently just a
> > proof of concept that only works on QEMU/arm64, but it should not be
> > too hard to adapt it for x86 and for booting a kernel that has already
> > been loaded to memory.
>
> The EFI stub carries out a bunch of actions that have meaningful
> security impact, and that's material that should be measured. Having the
> secure launch kernel execute the stub without awareness of what it does
> means it would need to measure the code without measuring the state,
> while the goal of DRTM solutions is to measure state rather than the
> code.

But how is that any different from the early kernel code?