Dear Maintainer,

   * What led up to the situation?
On system with: bookworm, 3 partitions (EFI, /boot, luks-encrypted-rootfs), 1 tpm, I am attempting to use either tpm2 or tpm2-with-pin in systemd-cryptenroll so that on book, my luks2 encrypted rootfs is able to automatically use the hardware tpm (ie. auto-unlock with just tpm or with tpm-pin). Then, update /etc/crypttab with tpm2-device=(tpm path) followed by run "update-initramfs -u" to apply changes I made to crypttab.
   * Expected outcome:
No warnings output from "update-initramfs -u). Then on boot, the system automatically utilises tpm2 to auto unlock or request tpm-pin (if set tpm-with-pin=yes in cryptenroll)
   * Actual outcome:
Both during output of "update-initramfs -u" AND during boot, I see the warning line: "cryptsetup: WARNING: nvme1n1p3_crypt: ignoring unknown option 'tpm2-device'" (also applies to "tpm2-pin" option). Unfortunately, on boot, as per the warning, the tpm remains unused and I am requested the other recovery key/password I have set (totally ignoring the tpm or tpm-with-pin slot within systemd-cryptenroll)
   * Why do you suspect this is a bug?
According to: https://github.com/systemd/systemd/releases/tag/v251-rc1 it says "Option tpm2-pin= can be used in /etc/crypttab." However, as stated above, this is not the case (tpm-device also does not work).
Others have experienced something similar: https://askubuntu.com/questions/1370877/unlock-root-disk-with-tpm2-on-impish-indri, https://answers.launchpad.net/ubuntu/+question/702266 with the only half-solution being a third party github patch: https://github.com/wmcelderry/systemd_with_tpm2
   * Anything else important?
This ONLY AFFECTS the root filesystem (rootfs). If I have another drive with its own encrypted partition, this works NORMALLY with NO errors. This means that on this system, if I add another drive, there will be no warnings from cryptsetup when running update-initramfs -u or on boot for the second drive, however, the warnings for rootfs remain (the second drive works properly with the tpm or tpm-with-pin, but rootfs does not).

Hi,


we also run into that bug on with cryptsetup 2:2.3.7-1+deb11u1 (debian
11 with backported packages cryptsetup+libs)


With this Bug encrypting Disks with key in tpm (a documented Feature) is
completely broken,

so it should be classified as bug.


Has anyone a workaround for that?


WG

This is documented in systemd not src:cryptsetup.  systemd is not
involved at early boot stage, at when least the initramfs image is build
with initramfs-tools (Debian's current default).  See crypttab(5).

Could you elaborate more on why this occurs and are there any ways to avoid
this issue?

I’ve looked at crypttab man page but couldn’t find relevant information.

(I’m new to Linux, so I don’t know too much)

Appreciate all the help,
JJ

Hi,

I got it working with a fix I found and modified from a Ubuntu version
to work also for Debian testing:
https://github.com/larssilven/systemd_with_tpm2

Cheers,
Lars

Oh, cool!  Unfortunately that's too late for bookworm, but will be
considered for trixie (and maybe also bookworm-backports) after the
bookworm release.

Currently, bookworm has been released. Can we look forward to apply this patch in trixie or sid?

On Thu, 29 Jun 2023 09:03:45 +0000 =?gb2312?B?zswgxubWvg==?=
<alim0x@outlook.com> wrote:
 > On Sun, 2 Apr 2023 18:36:51 +0200 Guilhem Moulin <guilhem@debian.org>
wrote:
 > > On Sun, 02 Apr 2023 at 12:57:58 +0200, Lars Silvén wrote:
 > > > I got it working with a fix I found and modified from a Ubuntu
version to
 > > > work also for Debian testing:
 > > > https://github.com/larssilven/systemd_with_tpm2
 > >
 > > Oh, cool! Unfortunately that's too late for bookworm, but will be
 > > considered for trixie (and maybe also bookworm-backports) after the
 > > bookworm release.
 > >
 > > --
 > > Guilhem.
 >

 > Currently, bookworm has been released. Can we look forward to apply
this patch in trixie or sid?


Hi, I just opened a merge request for supporting TPM2
https://salsa.debian.org/cryptsetup-team/cryptsetup/-/merge_requests/39

@Guilhem,@Lars could you please review/test?

BR
Armin

Hello,

I was wondering if there was any progress with this bug report.

The past few messages and the MR with the bugfix are from mid-2024 and talk about possibly getting the bugfix into trixie, which has since been released a year ago. There hasn't been any activity in the MR in almost a year.

I've been running the patch from Lars Silvéns Github repository, without issues.

Is there a chance this will be fixed in time for forky next year?

Best regards,
Florian