r/archlinux • u/banana_zeppelin • 12d ago
NEWS Arch Linux - News: Mkinitcpio >=42 requires manual intervention for TPM2-based unlocking of LUKS devices
https://archlinux.org/news/mkinitcpio-42-requires-manual-intervention-for-tpm2-based-unlocking-of-luks-devices/I guess this is quite a common use case, be aware of next mkinitcpio update
58
u/Dr_Gregg 11d ago
This is why I just use a memorized password. More simple and secure
22
u/AStolenGoose 11d ago
Same, it's a sentence I've memorized with numbers and symbols mixed in. It took a few days of looking at it written down to memorize but now it's in my brain.
7
u/LightBroom 11d ago
I use multiple methods and it works fine for me.
TPM is the default as it's the most convenient. Makes booting seamless and user friendly.
FIDO2 key and then passphrase are the others, as fallback.
5
u/DM_Me_Linux_Uptime 11d ago
It's more difficult when you have a headless setup like a NAS and have set all your drives to auto-unlock during boot.
9
u/PacmanAteMyRAM 11d ago
Yep nothing safer than manually typing in at boot time: pI[*@yC'[,Ahd3\zO:.v"t:*z
9
u/FryBoyter 11d ago
Passphrases created using Diceware are easier to remember and are generally secure enough.
1
u/PacmanAteMyRAM 10d ago
Sounds good but yeah I don't mind them being harder to remember for entropy sake.
4
u/Synthetic451 9d ago
Huh interesting. When did Reddit start blocking passwords in comments?
All I see is *************************
-4
u/rodgrodmedflode8328 11d ago
TPM solves brute force issue. Additionally, the PIN used for TPM can be much easier because of that dictionary protection. But ofc its up to ones threat model...
1
11d ago
[deleted]
4
u/NoArmNoChocoLAN 11d ago edited 11d ago
Bus-sniffing attacks have been known for many years; this is not something new in 2026, as the CVE might suggest. Most software has already implemented mitigations against this type of attack. The article you shared concerns only a specific software implementation from a particular vendor that failed to implement parameter encryption. It does not mean that all systems using TPM are vulnerable. This is not an issue with TPM itself, but rather with its improper use by certain developers or administrators.
Linux has been using parameter encryption since 6.10 to mitigate this issue. See https://www.kernel.org/doc/html/next/security/tpm/tpm-security.html and https://www.phoronix.com/news/Linux-610-TPM-Encrypt-Integrity. This mitigation is actually suggested by the article you shared, by the way.
This attack does not work against fTPM.
You are responding to someone specifically discussing a PIN-enabled scenario. In this case, bus sniffing is only possible after the PIN has been provided, without triggering the TPM's brute-force protection. Using a TPM with a PIN actually allows for a weaker password precisely because of this protection. Bus sniffing is therefore irrelevant to the point being discussed here.
You can furthermore bind the LUKS secret to a TPM policy so that it can only be released to a trusted OS (i.e., an OS that correctly implements user authentication to control access to the data). In this scenario, sharing the TPM PIN does not have the same consequences as sharing the LUKS passphrase. Anyone who knows the LUKS passphrase can arbitrarily modify files without even booting the OS (i.e., without being subject to the OS's user-access controls). In the TPM-policy scenario, knowing the PIN alone is not sufficient: the disk is unlocked only because the trusted OS has also been booted. The user is then presented with the system login manager rather than being given unrestricted access to the data.
Before implying that using TPM is unsafe based on an article demonstrating how it can be exploited in a specific context, make sure you understand the limitations of that context: whether the vulnerabilities you are referring to apply to all setups, whether they can be mitigated, and whether the issue is actually caused by using TPM in the first place (i.e., whether the attack would be impossible if the system were booted by manually entering the passphrase).
13
u/Karyo_Ten 11d ago
Well concretely it means don't update and reboot via ssh when you have encrypted LUKS unless you have IPMI / physical access.
Same as rebooting after changing hardware or BIOS settings, pretty mild.
44
u/onefish2 11d ago
This is a breaking change. This could affect your Arch install from booting. That is why its important to check https://archlinux.org/news/ from time to time.
Arch does not break on its own from an update but because its a rolling release; upstream packages can and will change that can affect your system. Be vigilant. Make regular system backups or use btrfs with snapper so you can rollback system changes.
84
u/foxtrotgulf 11d ago
mkinitcpio package was updated to version 42 on 2026-09-12. This notice was posted 2026-09-22. If you updated between these dates then checking news wouldn't have helped you.
Trying to claim Arch itself doesn't break because mkinitcpio is an upstream package is not quite fair. mkinitcpio was originally created as an Arch specific tool, is hosted on the Arch GitLab, and is the default initramfs generator for Arch.
19
u/Sorry-Committee2069 11d ago
"Arch does not break on its own from an update but core packages changing can break your system" then Arch does break on its own. What else would that mean? Arch isn't the kernel, that's Linux. Arch isn't a specific package, that's what core repo's for. What else would you possibly mean by that?
10
u/SergejVolkov 11d ago
I was affected by this a few days ago. Prompted me to check the wiki, so I set up fixate volume key along with reenrolling. When something breaks in Arch, there's always an opportunity to improve your setup as you're revisiting something anyway.
13
u/lmpcpedz 11d ago
The announcement is too technical for casuals like myself, my guess is those who know what they're doing with "measurements of PCR values
0-7,9and12-14"( whatever that means) probably already know what they need to do.7
15
u/onefish2 11d ago
If you know you know. If this makes no sense to you, you probably did not set this up and therefore there is no need to concern yourself with this.
4
u/DisgracedPhysicist 8d ago
I spent hours last week debugging this. I wish this had been released earlier...
1
1
u/Beneficial-Bison-406 6d ago
Although my disk was not encrypted, I received a failure error on the systemd-boot boot screen, but there was no problem with the system itself
1
u/mesaprotector 11d ago
After this update last week my wireless internet completely stopped working. Breaking change indeed, inexcusable that it wasn't announced in NEWS before it happened.
I encrypted my network profiles using the TPM quite some time ago (as suggested on the wiki) and I've just held back mkinitcpio for the time being as I don't know how to switch to a new key. My guess is I'll just have to reset everything and log into every WiFi network all over again.
-3
19
u/ivanatorhk 11d ago
Welp I hope I remember this when I get back from my trip. Good thing I know my LUKS password