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] [day] [month] [year] [list]

Message-Id: <D6B4BRNN9S4U.IJ3IU91D6YRB@kernel.org>
Date: Sat, 14 Dec 2024 05:54:26 +0200
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "James Bottomley" <James.Bottomley@...senPartnership.com>, "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>, "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 Tue Dec 10, 2024 at 3:04 PM EET, James Bottomley wrote:
> On Tue, 2024-12-10 at 07:13 +0100, Jiri Slaby wrote:
> [...]
> > Perhaps, you can give a hint why those happen exclusively with 6.12+?
>
> For which one: the ramdisk size not being modulo 4 or the unseal
> getting a PCR changed error?  For the former I don't have much of an
> idea, it would seem to be a dracut (or whatever initrd builder you use)
> issue; the kernel doesn't care about the ramdisk size.  For the latter,
> I would suspect something is delaying IMA measurements such that
> they're still going on when you're trying to unseal.  The error you're
> getting occurs if any PCR changes, not just the ones the policy is
> locked to (thanks TCG).  We have had syzbot reports of processes
> getting stuck in measurement that have been identified as exfat
> related:
>
> https://syzkaller.appspot.com/bug?extid=1de5a37cb85a2d536330
>
> But it could be a more generic filesystem issue that measurement is
> slowing but not enough to trigger the stuck process warning.
>
> In particular systemd parallelizes a lot of stuff, so if it's doing
> something that causes IMA measurement in parallel with the unseal and
> this parallel process finished before unseal on an earlier kernel, that
> would explain it.  You could probably verify this by adding more
> dependencies to the tpm target, but I'm not really well versed in
> systemd.

Yeah, I agree. This is too much looking for needle from the haystack.
A bit more evidence for kernel issue is needed than just kernel version
change in order to make progress.

> Regards,
>
> James

BR, Jarkko