linux-kernel - Re: TPM/EFI issue [Was: Linux 6.12]

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: <02060553aafac7e145e96510a66a6845d389d6ff.camel@HansenPartnership.com>
Date: Fri, 29 Nov 2024 11:03:59 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Jiri Slaby <jirislaby@...nel.org>, Linus Torvalds
	 <torvalds@...ux-foundation.org>, Linux Kernel Mailing List
	 <linux-kernel@...r.kernel.org>
Cc: Peter Hüwe <PeterHuewe@....de>, Jarkko Sakkinen
	 <jarkko@...nel.org>, Jason Gunthorpe <jgg@...pe.ca>, 
	linux-integrity@...r.kernel.org, Ard Biesheuvel <ardb@...nel.org>, 
	"linux-efi@...r.kernel.org"
	 <linux-efi@...r.kernel.org>
Subject: Re: TPM/EFI issue [Was: Linux 6.12]

On Fri, 2024-11-29 at 07:36 +0100, Jiri Slaby wrote:
> On 28. 11. 24, 17:13, James Bottomley wrote:
[...]
> > Yes, it tells me the entries in the log for PCR0-7,14 match the log
> > entries (for both sha1 and sha256).  However there are entries for
> > PCR9,12 which don't match.  The log shows shim starting at entry
> > 32, grub starting at entry 37 and the kernel loading at entry 39 
> > the kernel command line logged at 40 to PCR 12, which is
> > mismatching.
> > 
> > The next two entries (41,42) are for the mismatching PCR9 and are
> > of the initrd and the options and come from the libstub code in the
> > kernel early boot (efi-stub-helper.c).
> 
> Note that ovmf logged:
> Called TcgDxeHashLogExtendEvent 0 58683000 1B1E78C 5FE63C00 5E3492AA
> Data 28 B5 2F FD ... E1 29 FE 0
> 
> But initrd on disk is 1B1E78B long, not 1B1E78C. So the excessive 0
> at the end above brews the mismatch. See:
>    https://bugzilla.suse.com/show_bug.cgi?id=1233752#c14
> "By adding the 0 byte I can replicate the measured digest."
> 
> So there is something aligning the initrd. kernel's libstub just uses
> and passes load_file2's size down to TcgDxeHashLogExtendEvent, AIUI.
> So it'd be sdb, ovmf or something. BTW how are sizes stored
> in/fetched from vfat?

Well, I was going to explain what EFI does, but it doesn't look
relevant now I've had a crash course reading the systemd-boot code.  It
looks like run() calls image_start() which loads the initrd itself. 
Then in initrd.c:initrd_prepare() it actually installs its own load
file2 protocol which is the protocol the kernel picks up when it loads
the initrd.  So whatever length the kernel is picking up is, in fact,
provided by systemd-boot.

I'd suspect something in this double indirection of load file protocols
is causing your length mismatch.

>  But well, fs/fat/ received no significant changes either.

We don't use that at all in the EFI stub (and neither does systemd-
boot).  We use the protocols EFI provides to read fat volumes, so any
issue would be in the edk2 (or in your case ovmf) FatPkg.

> > This code was last updated in 6.9, so it seems unlikely to have
> > suddenly caused a problem.  Event 43,44 are exit boot services
> > (logged to PCR 5 which matches). line 40 is anomalous: grub is
> > supposed to measure the options to the string PCR which should be 8
> > not 12 ... did you patch grub to change this?
> 
> All this is with sdb, not grub, actually.

It is?  Grub clearly appears in your log in event 37:

>     SubType 04 File Path
>       Path Name: \EFI\systemd\grub.efi
>     Type 7f End of Hardware Device Path

But I figured it out: shim is hard coded to look for grub.efi  In any
case, the entries match what systemd-boot would write (it seems to
insist that the string PCR is 12 instead of 8, which explains the log
entry).

However, this still doesn't explain the mismatch between the log and
the PCRs (even if you've got the wrong initrd hash, it should be
correctly recorded), but I suspect something updates them later in the
boot sequence without adding a log entry.

> > The log can't be corrupt because PCR8 is zero, so nothing got
> > logged to it.
> > 
> > And do you have the same thing for a working system?
> 
> Let me try.

Thanks, that will at least tell me if something booting via systemd is
supposed to be able to match log entries on these PCRs (I'm suspecting
no is the answer).

I'm also trying to set up my own systemd-boot system.

James