Cryptsetup does not understand tpm2-device option
The end goal is to have tpm2 autounlock using systemd-
I have this working on fedora
The pieces needed are tpm2-tools
a tpm2 chip/ post gen 8 intel proccessor
the tpm2-tss module
You enroll the key in the tpm register 7 with
systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sdx
You update crypttab to put tpm2-device=
then you add the tpm2-tss to the initramfs module list and update-initramfs
The last step makes it look like cryptsetup is not built to support tp2 devices. Is this something that needs to be updated with cryptsetup?
update-initramfs: Generating /boot/initrd.
cryptsetup: WARNING: sda3_crypt: ignoring unknown option 'tpm2-device'
Question information
- Language:
- English Edit question
- Status:
- Needs information
- For:
- Ubuntu Edit question
- Assignee:
- No assignee Edit question
- Last query:
- Last reply:
Revision history for this message
|
#2 |
I am aware of the system-cryptenroll bug thread, I'm the last poster on it.
The issue I am having is with cryptsetup, systemd-cryptenroll enrolls the key in the tpm properly
Revision history for this message
|
#3 |
https:/
https:/
Read the very last entry on github.
Has to do with Trust and permissions.
Edit the permissions and the trust of signed ca certs for server.
https:/
Question: Do you have LUKES2-partitioning ?
Revision history for this message
|
#4 |
None of these are the same issue.
The error it gives is pretty self-explanatory, cryptsetup does not think tpm2-device is a valid option, for engaging with the partition.
root@ubuntu:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.
cryptsetup: WARNING: sda4_crypt: ignoring unknown option 'tpm2-device'
root@ubuntu:~# cat /etc/crypttab
sda4_crypt UUID=1e25ad74-
The TPM has decryption keys registered in slot number 7. To Auto decrypt a luks2 partition.
I don't think this has anything to do with trust and permissions or exotic configs. I think this has to do with the builds not having TPM2. support enabled. Systemd-cryptenroll was just compiled with it on 2 days ago in jammy-updates.
Revision history for this message
|
#5 |
For diagnostic purposes, what is the output of the commands
uname -a
lsb_release -crid
command -v update-initramfs
command -v cryptsetup
dpkg -S $(command -v update-initramfs) $(command -v cryptsetup)
apt policy initramfs-tools cryptsetup-bin
Revision history for this message
|
#6 |
here you go
root@ubuntu:~# uname -a
Linux ubuntu 5.15.0-40-generic #43-Ubuntu SMP Wed Jun 15 12:54:21 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
root@ubuntu:~# lsb_release -crid
Distributor ID: Ubuntu
Description: Ubuntu 22.04 LTS
Release: 22.04
Codename: jammy
root@ubuntu:~# command -v update-initramfs
/usr/sbin/
root@ubuntu:~# command -v cryptsetup
/usr/sbin/
root@ubuntu:~# dpkg -S $(command -v update-initramfs) $(command -v cryptsetup)
initramfs-tools: /usr/sbin/
dpkg-query: no path found matching pattern /usr/sbin/
root@ubuntu:~# apt policy initramfs-tools cryptsetup-bin
initramfs-tools:
Installed: 0.140ubuntu13
Candidate: 0.140ubuntu13
Version table:
*** 0.140ubuntu13 500
500 http://
500 http://
100 /var/lib/
cryptsetup-bin:
Installed: 2:2.4.3-1ubuntu1
Candidate: 2:2.4.3-1ubuntu1
Version table:
*** 2:2.4.3-1ubuntu1 500
500 http://
100 /var/lib/
Revision history for this message
|
#7 |
Strange.
In https:/
Do you have the package libtss2-rc0 installed?
Revision history for this message
|
#8 |
right,it worked for dean huffman but there are two of us in that thread having the 'cryptsetup doesnt understand tpm2-device'
I'm guessing hes got packages or package versions on his testbox that we dont have.
root@ubuntu:~# apt install libtss2-rc0
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libtss2-rc0 is already the newest version (3.2.0-1ubuntu1).
Revision history for this message
|
#9 |
You might consider trying to contact dean huffman to ask him about the package versions that he has.
Revision history for this message
|
#10 |
@christopher88hall, which packages are you looking for specifically? For my setup, I install my machines with via a clout-init script, the encrypted luks partitions already existed on the system prior to me upgrading systemd and setting up systemd-
here's what my test box is running for starts with systemd & starts with crypt:
root@testbox:~# apt list | egrep -i '^systemd|^crypt' | grep installed
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
cryptsetup-
cryptsetup-
cryptsetup/
systemd-
systemd-
systemd-
systemd/
Revision history for this message
|
#11 |
Im not exactly sure what Im looking for here, Some possible reason why 2 of us are hitting the cryptsetup doesnt know what tpm2-device=auto is while you didnt. This is a fresh ubuntu 22.04 lts luks2 encrypted from the beginning. I know you method works because Ive replicated it on fedora, but something is off inside ubuntu 22.04
The versions look the same,
Here's the diff between mine and yours
for some reason my cryptsetup-
chris@testbox:~$ diff mine his
1,3c1,3
< cryptsetup-
< cryptsetup-
< cryptsetup/
---
> cryptsetup-
> cryptsetup-
> cryptsetup/
5d4
< systemd-
Revision history for this message
|
#12 |
Is the option 'tpm2-device' contained in /etc/fstab or in /etc/crypttab (or both)?
In any case, it is just shown as "warning" and should not do any harm.
Revision history for this message
|
#13 |
@Dean Huffman:
Do you have 'tpm2-device=auto' in your /etc/crypttab file?
Revision history for this message
|
#14 |
On my target device, I have a fairly complex set of partitions to support lvm snapshots and read-only file systems when run in a production environment. This particular box hasn't been configured with either read-only or snapshots yet.
In short, the vg_system volume group is unencrypted while the vg_skyview volume group contains all the encrypted logical volumes. See output of files below:
root@testbox:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/vg_
/dev/disk/
# /maptiles was on /dev/vg_
/dev/disk/
/dev/disk/
# /var/log was on /dev/vg_
/dev/disk/
# /home was on /dev/vg_
/dev/disk/
# /opt/skyview was on /dev/vg_
/dev/disk/
# /services was on /dev/vg_
/dev/disk/
# /var/log/skyview was on /dev/vg_
/dev/disk/
# /upload was on /dev/vg_
/dev/disk/
# /var/apps was on /dev/vg_
/dev/disk/
# /boot was on /dev/sda2 during curtin installation
/dev/disk/
# /boot/efi was on /dev/sda1 during curtin installation
/dev/disk/
/swap.img none swap sw 0 0
root@testbox:~# cat /etc/crypttab
#dm_crypt-0 UUID=6e4e776f-
dm_crypt-0 UUID=6e4e776f-
root@testbox:~# lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv_home vg_skyview -wi-ao---- 15.00g
lv_opt_skyview vg_skyview -wi-ao---- 1.00g
lv_services vg_skyview -wi-ao---- 1.00g
lv_upload vg_skyview -wi-ao---- 15.00g
lv_var_
lv_maps vg_system -wi-ao---- 185.00g
lv_root vg_system -wi-ao---- 20.00g
lv_swap vg_system -wi-ao---- 5.00g
lv_var_apps vg_system -wi-ao---- 9.41g
lv_var_log vg_system -wi-ao---- 10.00g
root@testbox:~# pvs
PV VG Fmt Attr PSize PFree
/dev/
/dev/sda3 vg_system lvm2 a-- <291.00g 61.58g
root@testbox:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 61.9M 1 loop /snap/core20/1328
loop1 7:1 0 61.9M 1 loop /snap/core20/1518
loop2 7:2 0 78.1M 1 loop /snap/lxd/22467
loop3 7:3 0 101.3M 1 loop /snap/lxd/23155
loop4 7:4 0 43.6M 1 loop /snap/snapd/14978
loop5 7:5 0 47M 1 loop /snap/snapd/16010
sda 8:0 0 447.1G 0 disk
├─sda1 8:1 0 1G 0 part /boot/efi
├─sda2 8:2 0 750M 0 part /boot
├─sda3 8:3 0 291G 0 part
│ ├─vg_system-lv_root 253:0 0 20G 0 lvm /
│ ├─vg_system-lv_maps 253:1 0 185G 0 lvm /maptiles
│ ├─vg_system-lv_swap 253:2 0 5G 0 lvm [SWAP]
│ ├─vg_system-
│ └─vg_system-
└─sda4 8:4 0 154.3G 0 part
└─dm_crypt-0 253:5 0 154.3G 0 crypt
├─vg_
├─vg_
├─vg_
├─vg_
└─vg_
root@testbox:~# blkid
/dev/mapper/
/dev/mapper/
/dev/mapper/
/dev/mapper/
/dev/sda4: UUID="6e4e776f-
/dev/sda2: UUID="8ae09c96-
/dev/sda3: UUID="HqoE9Y-
/dev/sda1: UUID="884C-5B54" BLOCK_SIZE="512" TYPE="vfat" PARTUUID=
/dev/mapper/
/dev/loop1: TYPE="squashfs"
/dev/mapper/
/dev/mapper/
/dev/mapper/
/dev/loop4: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/mapper/
/dev/mapper/
/dev/loop5: TYPE="squashfs"
/dev/mapper/
/dev/loop3: TYPE="squashfs"
Revision history for this message
|
#15 |
I think it's got to be something to do with the way the system is installed, a missing package or something like that. I think the cloud-init system is doing something differently than the 2204 ISO.
I did notice when we were looking at those packages earlier several of yours said installed, automatic. Where the ones that came off the iso didn't say that so I'm wondering if there's some kind of meta package that includes some other packages that might act as plugins to cryptsetup that the 2204 ISO doesn't
Revision history for this message
|
#16 |
I wanted to test this out on ubuntu server, as that appears to be what the cloud-init stuff relates to and I am hitting the same issue
root@test:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.
cryptsetup: WARNING: dm_crypt-0: ignoring unknown option 'tpm2-device'
After additional combing through dean's output above it looks like /dev/sda4 6e4e776f-
I have noticed that dean's /dev/sda4 that the tpm is unlocking is not a root device, I am testing that angle to see if it works a non-root device
Revision history for this message
|
#17 |
I am quite sure that the message comes from /lib/cryptsetup
@Christoper Hall and @Dean Huffman, can you both please report the output of
grep "ignoring unknown option" /lib/cryptsetup
grep tpm2 /lib/cryptsetup
Revision history for this message
|
#18 |
This tested as working on a non-root filesystem.
So thats why its working on his box and not for the others.
I tested it by adding another 1Gig virtual harddrive and manually partitioned it, luksformatted it, and put ext4 on it. I threw it in the crypttab file. Enrolled the keys for it in the tpm register. Update- Initramfs didnt throw any errors and the crypt container was popped open when I rebooted without manual inputs.
dns-support@test:~$ grep "ignoring unknown option" /lib/cryptsetup
dns-support@test:~$ grep tpm2 /lib/cryptsetup
Its not included in the functions there in that /lib/cryptsetup
Revision history for this message
|
#19 |
I know this is very much offroading but I swapped in dracut inplace of ubuntu's native system., because I wasnt getting this issue with fedora.
It had all kinds of errors, but it didnt complain about tpm2-device=auto. So it looks to be narrowed down to how the initramfs is built. It looking like a bug report but Im not sure where to file it
dns-support@test:~$ sudo dracut --regenerate-all --force > dracutoutput
dns-support@test:~$ grep tpm2 dracutoutput
dns-support@test:~$
Revision history for this message
|
#20 |
@m-hampl
root@testbox:~# grep "ignoring unknown option" /lib/cryptsetup
root@testbox:~# grep tpm2 /lib/cryptsetup
root@testbox:~#
Revision history for this message
|
#21 |
"why does it work then"
My interpretation of the "functions" script:
The message is just a warning.
The only effect is that the "tpm2-device=auto" option is not forwarded to the following steps (whatever they are).
Apparently the next steps don't need it anyhow.
Ideas for possible next steps (not sure whether worth trying):
- add -v (verbose) to update-initrams (attention lots of output!)
- modify /lib/cryptsetup
somewhere between line 227 ("# and now the flags") and line 247 (a few lines above the message "ignoring unknown option")
The important question is:
Does your setup work despite the "ignoring unknown option" message?
Revision history for this message
|
#22 |
>Does your setup work despite the "ignoring unknown option" message?
No it does not use the tpm2 to decrypt the root filesystem. The end goal is to be able to turn the system on, have the tpm2 chip decrypt it and hit the login screen without any input. I've managed to get arch and fedora to do this so I know its possible.
>- modify /lib/cryptsetup
> somewhere between line 227 ("# and now the flags") and line 247 (a few lines above the message "ignoring unknown option")
I actually tried this earlier, and followed the error chain. It leads to
/usr/share/
CRYPTTAB_
this makes me think initramfs-tools is the guity party, but maybe cryptsetup?
fedora and ubuntu both seem to be running the same version of cryptsetup buy maybe they were compiled differently?
Revision history for this message
|
#23 |
"this makes me think initramfs-tools is the guity party, but maybe cryptsetup?"
The script /usr/share/
Revision history for this message
|
#24 |
interesting, these initrd governing systems seem very different, I cant find a cryptroot at all on the fedora machine except a cryptroot-ask.sh which looks nothing like the cryptroot file on ubuntu.
So if I were to make a bug report It would go under cryptsetup or maybe just keep the original bug thread going? The original issue with systemd-cryptenroll is a solved and fixed issue. That part does it's job well. This bug is just the next one down the road towards tpm2 unlocked systems
Looks like its this package that is responsible for cryptroot
https:/
Revision history for this message
|
#25 |
I've been experiencing a very similar issue to Christopher Hall.
Only for root filesystem:
- Crypsetup complains "WARNING : ... : ignoring unknown option 'tpm2-device' (as well as 'tpm2-pin') when running "update-initramfs"
- On boot, the root filesystem does not try to unlock via tpm at all; it immediately attempts to ask for password/recovery key (ie. the other unlock methods)
- Does not matter if I try tpm or tpm-with-pin; problem persists
It is very important to add that this only affects the root filesystem; I have a second drive attached to the system that works perfectly normally, unlike the errors above experienced by only the root filesystem. This means that while at boot I have the enter password/recovery key for root filesystem, I am still prompted (shortly afterwards) to enter my TPM-Pin (or auto-unlock with no prompt if just using tpm) to unlock the other drive's filesystem.
When I try attaching the root filesystem after boot, it seems to work normally with the tpm; I don't know why.
FYI: I'm trying to get "tpm-with-pin" working however the root filesystem does not want to work on boot (so Will McElderry's script only solves half the problem)
Has anyone resolved the issue yet?
(I'm on "Debian Bookworm", but posting here as Christopher seems to be experiencing an identical problem)
Revision history for this message
|
#26 |
https:/
There is another parallell bug report on this
Where it sits right now is the devs dont want to take the time to fix it because "It's not perfectly secure" despite almost none of the other options for luks unlocking also being perfectly secure, and most other distros having added support for it already. It was added to the wished for items list months ago and nothing has happened with it until you posted here.
Will's patches fix it.
Can you help with this problem?
Provide an answer of your own, or ask Christopher Hall for more information if necessary.