ferdleel denzyll giovany
Mireille Duhon
System boot fine, but this is showing in spite of my silent boot efforts. And it's strange, since I've never used Secure Boot or TPM2 in any way. My guess is that the latest initramfs.img contains the effort to start TPM2 barrier, even though I don't want to.
Tpm2-tss is installed. It is a dependency for libsecret, which in turn is necessary for several things (Bitwarden, for example). So I cannot simply remove it. But it should not try to start TPM2 barrier on boot. Again, it appears to be part of the initrd (See error message quotes in original post). But I don't know why, nor how to stop it from happening.
I've added console=tty2 to my kernel cmdline and that means that the error message doesn't show during the boot process (which, of course, is not the same as the error not occurring). I'd much prefer if systemd didn't automatically force tpm2 to be a part of initrd...or at least make is possible to not include it...but in the meantime, I'll live with the message not printing to my console.
I think someone should request be reopened.
Edit:
If you add /usr/lib/libtss2-esys.so.0 to the BINARIES array of /etc/mkinitcpio.conf then rebuild the initrd, is the error message still produced? Is so please post the journal for that boot.
I thought libtss2-rc.so.0 libtss2-mu.so.0 were both depends of libtss2-esys.so.0 so adding that would be enough. I had mistaken libtss2-sys.so.1 for libtss2-rc.so.0.
So at least libtss2-esys.so.0 and libtss2-rc.so.0 need to be in the binaries array. Then rebuild the initrd. Then check
The addition of binaries worked for those of us not using secure boot as well. I've marked the thread solved and thank everyone for the assistance. I did not try the sd-encrypt hook suggested by @NeverTooLate
OK, tested with sd-encrypt hook suggested by @NeverTooLate (removed libtss2* from BINARIES) and the PCR barrrier error is not displayed. So now we have two "solutions", both working but ugly:
- using hardcoded libtss2* BINARIES
- using sd-encrypt which brings a warning regarding missing firmware for qat_4xxx from mkinitcpio
They are ugly because they both require configuration (either BINARIES or HOOKS) for TPM or encryption even if the functionality (encrypted filesystem) is not used at all, otherwise we are getting error messages.
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.
@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-cryptenroll.
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
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.
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
After additional combing through dean's output above it looks like /dev/sda4 6e4e776f-96f2-4124-be2d-95c5bad15c0b is not the root filesystem, that's about the only discrepancy I can find. That still doesnt make any sense as to why cryptsetup couldnt interpret it
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.
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.
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.
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
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.
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.
This tutorial is a bit outdated, some tools matured well, some AUR stuff is not necessary anymore, a revision is coming.
By its nature this post is a response to the question once asked by @linux-aarhus and several other people (@Arisa @muvvenby). Hope you folks will find it useful.
PS: all commands were checked by me before posting. If you find anything being weird / unclear, do not hesitate to post and correct me as my bash / shell in general skills leave much to be desired.
Before you begin tinkering with system files, install all required tools:
yay -S sbsigntools efitools tpm2-tools tpm2-tss-git tpm2-totp-git plymouth-git sbupdate-git shim-signed
Some tools have to be git versions as you can see above due to a slow pace at which they get updated in the repository, while Linux kernel and systemd elolve quite fast.
The first step is to enable Secure Boot support. Normally it should be disabled because if using its default settings it prevents Manjaro from booting, but as it is required for ensuring that only allowed code is executed, you need to enable it as follows:
mkdir -p -v /etc/efikeys
chmod -v 700 /etc/efikeys
cd /etc/efikeys
The rationale behind using sha256 is that it is more secure than sha1 but you are free to use any supported protocol especially if there are some limitations implied by your BIOS, which is a quite common thing for many laptops.
I doubt that plymouth can cause this, I for one use a common sddm.service and it works fine with plymouth.
How does it look? You enter the password and hit Enter, and nothing happens? On Plymouth screen you can press Esc and see a standard boot text wall.
The sequence should be as follows: first you edit /etc/crypttab.initramfs, then do mkinitcpio -P and then run sbupdate (given that /etc/sbupdate config has been edited). After reboot, systemd-cryptenroll command. Before rebooting, it could be a good idea to check if crypttab is present in initrd image with lsinitcpio /boot/initramfs-5.10-x86_64.img grep crypttab.
Please use the mailing list at for general questions. The Issue Tracker ongithub should be reserved for actual feature requests or bugs. For security bugs, please see CONTRIBUTING.mdfor information on how to submit those.
This is the ESAPI dependency mentioned in INSTALL.md. This is the enhanced software API to the tpm. The tpm2-toolsproject relies heavily on this. -content/uploads/TSS_ESAPI_Version-0.9_Revision-04_reviewEND030918.pdf
I am trying to create a TPM-based unlock script using tpm2-tools with instructions from Tevora Secure boot tpm2. I have set up the key, loaded it with cryptsetup luksAddKey secret.bin, then tested it using tpm2_unlock -c 0x81000000 --auth pci:sha1:0,2,3,7 and returns the value of secret.bin. For extra measures, to make sure it works, I loaded secret.bin into "/etc/crypttab", ran # update-initramfs -u -k all, and rebooted. Upon reboot, the system unlocked.
After making the initramfs, you can run the following to ensure that the TPM related files are actually in the image. Replace the path in the filename by whatever update-initramfs said it was generating:
I pulled out various bits into variables at the top of the file. Modify TPM_REGISTER and TPM_SEAL_POLICY to match how you created the TPM object. set -e was removed since if any command failed, the whole script would exit, preventing the askpass fallback from ever running if tpm2_unseal failed.
Additionally, I noticed that if the script fails for some reason, systemd will attempt to run it again. If the secret in the TPM doesn't match the LUKS key, this will render the system unbootable, since the unseal succeeds, but unlocking fails, and systemd will run the script again.
Looking at the man page for crypttab, I discovered that one of the environment variables provided to the keyscript is CRYPTTAB_TRIED which is the number of tries it has attempted to unlock the volume. If CRYPTTAB_TRIED is 0, it'll attempt to use the TPM, as shown by this test (Running as non-root, so accessing the TPM device fails):
Warning: This post does not discuss initramfs configuration. Configuration of the initramfs is distribution specific. Effort needs to be taken to ensure that the initramfs does not have a recovery shell or similar functionality.
c01484d022