encryption causing very slow booting

kremooo · Yesterday 22:27:25

Every time I install Arch Linux on my computer and decide that I want disk encryption, the booting of my computer becomes slow, really slow. Here is the output of my systemd-analyze:

Startup finished in 5.759s (firmware) + 3.362s (loader) + 4.769s (kernel) + 1min 7.202s (initrd) + 2min 59.315s (userspace) = 4min 20.408s
graphical.target reached after 2min 59.314s in userspace.

My boot times before disk encryption were under than 10 seconds.

The wiki page I followed to set up boot encryption is the one that helps setting up disk encryption with secure boot and TPM: https://wiki.archlinux.org/title/Dm-cry … ire_system

Please let me know if there is any information I can provide to help fix this issue.

cryptearth · Today 02:38:39

kremooo wrote:

Please let me know if there is any information I can provide to help fix this issue.

at the very least a brief list of your hardware

ditch secureboot and the tpm - neither of them grant you the protection you might assume from them (unless you use ms-signed shim you use your own keys anyway - this already breaks the entire idea of secureboot)

what's your actual threat vector?

kremooo · Today 06:47:34

Sorry, the information from my first post was indeed insufficient.

Here is my brief list of the hardware I am using:

Computer: 2021 HP Omen Laptop 15.
CPU: AMD Ryzen 7 5800H.
GPU: Nvidia RTX 3060 (6GB VRAM)
Extras: Nvme SDD storage, 16 GB DDR4 RAM.

cryptearth wrote:

what's your actual threat vector?

It is not actually about the my threat model. I just want to make good use of my hardware, and giving up just because of an issue that hopefully can be fixed is not a thing I like.

Here is some extra info that should've made it to the first post:

When I go to the BIOS menu and hide the TPM from my operating system, first of all I am prompted to enter the disk decryption password or the TPM recovery key, and if I do, the system boots normally again.

Second, in the boot messages (I am not using the "quiet" parameter), the processes that are making my booting slow all have to do with TPM and all have TPM in the name (for example, TPM SRK). Here is the output of my systemd-analyze blame:

1min 54.740s systemd-tpm2-setup-early.service
1min 13.729s systemd-pcrproduct.service
1min 11.767s sys-devices-LNXSYSTM:00-LNXSYBUS:00-MSFT0101:00-tpm-tpm0.device
1min 11.767s dev-tpm0.device
1min 11.758s sys-devices-platform-serial8250-serial8250:0-serial8250:0.2-tty-ttyS2.device
1min 11.758s dev-ttyS2.device
1min 11.754s dev-ttyS0.device
1min 11.754s sys-devices-platform-serial8250-serial8250:0-serial8250:0.0-tty-ttyS0.device
1min 11.753s dev-ttyS1.device
1min 11.753s sys-devices-platform-serial8250-serial8250:0-serial8250:0.1-tty-ttyS1.device
1min 11.751s sys-devices-LNXSYSTM:00-LNXSYBUS:00-MSFT0101:00-tpmrm-tpmrm0.device
1min 11.751s dev-ttyS3.device
1min 11.751s sys-devices-platform-serial8250-serial8250:0-serial8250:0.3-tty-ttyS3.device
1min 11.751s dev-tpmrm0.device
1min 11.742s sys-module-fuse.device
1min 11.740s sys-module-configfs.device
1min 11.341s dev-nvme0n1p2.device
1min 11.341s dev-disk-by\x2dpath-pci\x2d0000:05:00.0\x2dnvme\x2d1\x2dpart2.device
1min 11.341s dev-disk-by\x2dpath-pci\x2d0000:05:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartnum-2.device
1min 11.341s dev-disk-by\x2ddiskseq-1\x2dpart2.device
1min 11.341s dev-disk-by\x2dpartuuid-b4637000\x2d1d5b\x2d4b00\x2d9ed5\x2dd3ae7720853d.device
1min 11.341s dev-disk-by\x2dpath-pci\x2d0000:05:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartuuid-b4637000\x2d1d5b\x2d4b00\x2d9ed5\x2dd3ae7720853d.device
1min 11.341s sys-devices-pci0000:00-0000:00:02.4-0000:05:00.0-nvme-nvme0-nvme0n1-nvme0n1p2.device
1min 11.341s dev-disk-by\x2did-nvme\x2dSAMSUNG_MZVLB1T0HBLR\x2d000H1_S4GRNX0NC12925\x2dpart2.device
1min 11.341s dev-gpt\x2dauto\x2droot\x2dluks.device
1min 11.340s dev-disk-by\x2dpath-pci\x2d0000:05:00.0\x2dnvme\x2d1\x2dpart-by\x2duuid-541e38e4\x2db6d2\x2d42d9\x2d93a9\x2d440bde7fbb16.device
1min 11.340s dev-disk-by\x2did-nvme\x2deui.0025388c01b33ab4\x2dpart2.device
1min 11.340s dev-disk-by\x2duuid-541e38e4\x2db6d2\x2d42d9\x2d93a9\x2d440bde7fbb16.device
1min 11.340s dev-disk-by\x2ddesignator-root\x2dluks.device
1min 11.340s dev-disk-by\x2did-nvme\x2dSAMSUNG_MZVLB1T0HBLR\x2d000H1_S4GRNX0NC12925_1\x2dpart2.device
1min 11.336s dev-disk-by\x2duuid-FA10\x2d3E59.device
1min 11.336s dev-disk-by\x2did-nvme\x2deui.0025388c01b33ab4\x2dpart1.device
1min 11.336s dev-disk-by\x2dpath-pci\x2d0000:05:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartnum-1.device
1min 11.336s dev-disk-by\x2dpath-pci\x2d0000:05:00.0\x2dnvme\x2d1\x2dpart-by\x2duuid-FA10\x2d3E59.device
1min 11.336s dev-nvme0n1p1.device
1min 11.336s dev-disk-by\x2did-nvme\x2dSAMSUNG_MZVLB1T0HBLR\x2d000H1_S4GRNX0NC12925_1\x2dpart1.device
1min 11.336s dev-disk-by\x2dpartuuid-6ff45817\x2d465e\x2d4fa6\x2dba4d\x2d7ebfe30fd0c7.device
1min 11.336s dev-disk-by\x2ddesignator-esp.device
1min 11.336s dev-disk-by\x2dpath-pci\x2d0000:05:00.0\x2dnvme\x2d1\x2dpart1.device
1min 11.336s dev-disk-by\x2dpath-pci\x2d0000:05:00.0\x2dnvme\x2d1\x2dpart-by\x2dpartuuid-6ff45817\x2d465e\x2d4fa6\x2dba4d\x2d7ebfe30fd0c7.device
1min 11.336s dev-disk-by\x2did-nvme\x2dSAMSUNG_MZVLB1T0HBLR\x2d000H1_S4GRNX0NC12925\x2dpart1.device
1min 11.336s sys-devices-pci0000:00-0000:00:02.4-0000:05:00.0-nvme-nvme0-nvme0n1-nvme0n1p1.device
1min 11.336s dev-disk-by\x2ddiskseq-1\x2dpart1.device
1min 11.335s dev-disk-by\x2did-nvme\x2dSAMSUNG_MZVLB1T0HBLR\x2d000H1_S4GRNX0NC12925.device
1min 11.335s dev-disk-by\x2did-nvme\x2dSAMSUNG_MZVLB1T0HBLR\x2d000H1_S4GRNX0NC12925_1.device
1min 11.335s dev-disk-by\x2did-nvme\x2deui.0025388c01b33ab4.device
1min 11.335s dev-nvme0n1.device
1min 11.335s dev-disk-by\x2ddiskseq-1.device
1min 11.335s dev-disk-by\x2dpath-pci\x2d0000:05:00.0\x2dnvme\x2d1.device
1min 11.335s sys-devices-pci0000:00-0000:00:02.4-0000:05:00.0-nvme-nvme0-nvme0n1.device
1min 7.663s sys-devices-pci0000:00-0000:00:08.1-0000:06:00.0-drm-card1-card1\x2deDP\x2d1-amdgpu_bl1.device
51.719s systemd-tpm2-setup.service
20.242s systemd-pcrfs-root.service
12.982s systemd-pcrmachine.service
6.590s systemd-pcrphase-initrd.service
4.080s systemd-pcrphase-sysinit.service
4.080s systemd-pcrnvdone.service
4.065s systemd-pcrphase.service
1.503s upower.service
941ms NetworkManager.service
926ms systemd-udev-trigger.service
821ms initrd-switch-root.service
732ms systemd-battery-check.service
404ms systemd-modules-load.service
225ms systemd-tmpfiles-setup-dev-early.service
184ms user@1000.service
172ms ldconfig.service
158ms systemd-userdbd.service
141ms systemd-journal-flush.service
101ms systemd-random-seed.service
99ms systemd-journald.service
96ms systemd-tmpfiles-setup.service
85ms systemd-boot-random-seed.service
80ms initrd-cleanup.service
80ms systemd-backlight@backlight:amdgpu_bl1.service
79ms polkit.service
78ms systemd-journal-catalog-update.service
78ms systemd-udevd.service
71ms systemd-tmpfiles-clean.service
70ms systemd-hostnamed.service
56ms systemd-logind.service
47ms dev-hugepages.mount
47ms dev-mqueue.mount
46ms sys-kernel-debug.mount
46ms systemd-tmpfiles-setup-dev.service
45ms sys-kernel-tracing.mount
38ms dbus-broker.service
37ms systemd-user-sessions.service
34ms tmp.mount
34ms sys-fs-fuse-connections.mount
34ms rtkit-daemon.service
33ms systemd-sysusers.service
33ms kmod-static-nodes.service
32ms systemd-fsck-root.service
32ms sys-kernel-config.mount
31ms user-runtime-dir@1000.service
29ms initrd-udevadm-cleanup-db.service
29ms systemd-vconsole-setup.service
27ms systemd-remount-fs.service
25ms systemd-rfkill.service
25ms systemd-update-done.service
25ms wpa_supplicant.service
24ms initrd-parse-etc.service
24ms systemd-ask-password-console.service
22ms systemd-userdb-load-credentials.service
22ms systemd-sysctl.service
20ms systemd-udev-load-credentials.service
19ms systemd-update-utmp.service
17ms boot.mount
8ms gpg-agent@etc-pacman.d-gnupg.socket
1ms polkit-agent-helper.socket
1ms systemd-factory-reset.socket
1ms systemd-coredump.socket
864us systemd-sysext.socket
792us systemd-ask-password.socket
792us systemd-mute-console.socket
680us systemd-bootctl.socket
637us systemd-creds.socket
556us systemd-pcrlock.socket
550us systemd-pcrextend.socket
544us systemd-repart.socket
261us dirmngr@etc-pacman.d-gnupg.socket
139us systemd-rfkill.socket
136us keyboxd@etc-pacman.d-gnupg.socket
105us dbus.socket
99us systemd-journald-dev-log.socket
98us gpg-agent-browser@etc-pacman.d-gnupg.socket
88us gpg-agent-extra@etc-pacman.d-gnupg.socket
87us gpg-agent-ssh@etc-pacman.d-gnupg.socket
73us systemd-journald.socket
70us systemd-machined.socket
64us systemd-userdbd.socket
56us systemd-importd.socket
54us systemd-udevd-varlink.socket
47us systemd-udevd-control.socket
46us dm-event.socket
41us systemd-hostnamed.socket
33us systemd-logind-varlink.socket
22us systemd-udevd-kernel.socket

Let me know if I can provide more information.

cryptearth · Today 07:33:29

please use code tags for console output, not quote

if you just disable the tpm without disable what depends on it - well, obvious you get even more issues

in your described usecase the entire idea is quite useless because it would only protect against someone removing the drive from the system and try to access external - as long as your system just unlocks itself and boot it aquivalent to hang the key open a lock right next to it - and secureboot does absolutely nothing for you here ither than posing another point of failure to yourself

full disk encrypting a laptop usually has the idea behind it to protect against theft or loss - which your setup just doesn't (yes, it would require quite sophisticated setup - but unless the tpm is integrated onto the cpu as a ftpm but a separate chip on the board its communication with the cpu often isn't protected itself - and someone could get the master key this way)

tl;dr: your most likely threat vector is that you will leave your device behind because in a split second you have something else in your mind - and to protect against that you should let your system ask you for a ohrase at boot
you can utilize the tpm in other ways - and just ditch secureboot, it does nothin for you
another threat vector could be when you travel international and customs wants to access your data - in the current config a state agency would have easy play because the system unlocks itself (yes, this is a real threat vector, just recently a german school teacher was held 5 weeks in us custody because instead of flying directly he flew to mexico and wanted to enter on food - his mistake was to unlock his phone)

if you want to benefit from full disk encryption on a mobile device have your system at least ask for a pin or phrase for the initial unlock - otherwise its useless

seth · Today 08:30:29

https://bbs.archlinux.org/viewtopic.php?id=312381

Arch Linux

#1 Yesterday 22:27:25

encryption causing very slow booting

#2 Today 02:38:39

Re: encryption causing very slow booting

#3 Today 06:47:34

Re: encryption causing very slow booting

#4 Today 07:33:29

Re: encryption causing very slow booting

#5 Today 08:30:29

Re: encryption causing very slow booting

Board footer