New question. Is the recovery key supposed to act like a normal LUKS passphrase? I have entered the recovery key manually when prompted at startup and it works fine.
But if I boot into a live session and attempt to open the LUKS encrypted volume, the recovery key is rejected.
How are we supposed to get our data back if the boot process fails?
On certified devices that ship with Ubuntu these features are usually turned off by default, RAID is a more general issue, but when Absolute is on it affects the boot process which can modify the expected hashes and cause the signatures to be rejected. Itās partly a feature in that we cannot accommodate external impacts on the boot process across devices, but partly a bug in that we need to provide better user feedback to detect whether these features are on and message that they need to be turned off. Weāre also investigating if we can do something to switch some of these off automatically when enabling TPM-backed encryption.
With regards your other question, attempting to access data via an external device (in this case the live session) is an example of the attack vector this feature is designed to address. however there is some tooling that could support a recovery flow through this route we are exploring.
Overall Iām really excited to try this out in production. Hopefully will be in a stable state for 24.04 LTS
I can see this being the tipping point for a lot of developers at our company switching the Ubuntu for their daily driver.
If the auto-unlock fails, how do you restore that functionality? We solved this by simply refreshing the pc-kernel snap, but is there an easier way to achieve this?
Iām having a similar issue here with the Intel MIPI camera in my thinkpad x1c11, the IPU6 modules arenāt part of the normal kernel package. Iām curious what the approach that yāall are looking at here, it strikes me that being able to install modules as snaps would be ideal, but I can imagine thatās probably not trivial functionality.
Is anyone with TPM-FDE experiencing their device restart when trying to wake from suspend?
It doesnāt happen every time though
There are no logs after the device suspends. It just performs a fresh boot as though it was shutdown instead.
Jan 09 16:24:10 ubu-n-b5c04f594433 systemd[1]: Reached target sleep.target - Sleep.
Jan 09 16:24:11 ubu-n-b5c04f594433 systemd[1]: Starting systemd-suspend.service - System Suspend...
Jan 09 16:24:11 ubu-n-b5c04f594433 systemd-sleep[377987]: Entering sleep state 'suspend'...
Jan 09 16:24:11 ubu-n-b5c04f594433 kernel: PM: suspend entry (s2idle)
Jan 10 08:20:10 localhost kernel: microcode: updated early: 0xa4 -> 0xac, date = 2023-02-27
Jan 10 08:20:10 localhost kernel: Linux version 6.5.0-14-generic (buildd@lcy02-amd64-031) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-4ubuntu3) >
Jan 10 08:20:10 localhost kernel: Command line: snapd_recovery_mode=run console=ttyS0,115200n8 console=tty1 panic=-1 quiet splash
As far as I remember the test device Iām using (Latitude 7420) didnāt have this issue before. I will test a newer kernel image and see if that has an effect.
Howdy there has been significant progress in the architecture and implementation of support for kernel modules and third party drivers, however at launch they will not be supported. Our plan however is to have these foundational elements in the image so we can expand HW compatibility within the lifecycle of 24.04. Our first priority will be to land NVIDIA driver support which is one of the most complex use-cases.
Thanks! Since it looks like its gonna be at least 6.10 until the IPU6 patches make it into the upstream kernel, Iāll continue to watch this with interest.
On a unrelated note, is anyone else having issues updating firmware? I get āUser has configured their system in a broken wayā from firmware-updater (which seems a bit judgey to me ;)) and
āSecure boot is enabled, but shim isnāt installed to EFI/ubuntu/shimx64.efiā if I try to run fwupdmgr.
Okay. Glad to know its not just me. It looks like its possible to disable secureboot, boot a live image, and queue the updates there, followed by rebooting and letting them install, followed by turning secure boot back on works.
What is the status on this? I just downloaded the 24.04.0 Desktop ISO and wanted to check out this feature after is has been announced for a while. The new installer looks great, but the TPM backed option was always in disabled state.
What I checked an tried:
Made sure that TPM Security Chip is enabled
Started the Ubuntu ISO from Ventoy
Used Rufus to create Bootable Media
Used Fedora Media Writer to create Bootable Media
Cleared TPM through UEFI settings and with this command:
echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request
Rebooted several times in the process and confirmed, that I do want to clear the TPM.
I checked the Arch Wiki and it said I should check with the following command and provide its output:
I donāt have that option. When I go the the āManage Keysā section I see a lot of SHA-265 hashes in the deny list.
Okay, that was it. I was certain it was disabled, bu I confused it with the line below which said not activated.
After I disabled āAbsoluteā I can now select TPM-backed encryption in the installer. Sorry that I didnāt check thoroughly. So many options.
Should I enable TSME?
Edit: And I need to disable 3rd party drivers to see the option. There is currently no explanation in the installer that one option excludes the other at this point in time.
Iām wondering, has anyone tested this installation option with the 24.04 images?
My few attempts resulted in unbootable systems. No UEFI boot entry is created and when I select the SSD in the boot menu Iām prompted to enter the recovery keys, which I donāt have yet.
I tried running sudo snap recovery --show-keys to get the recovery keys, but it returned that it is not running an encrypted system. Do I have to do some kind of chroot trickery with /target?
Edit: I just tried installing on my older T580 (Intel processor). And it worked. What was different? I didnāt care about network connectitivity and updates, so I installed offline to check. Back to my P14s, installing offline also works! But it feels ānot rightā without the boot entry. I mean I can adjust the boot priority, thatās not a big deal. I will test some more to write a good bug report.
No trickery should be required if your device supports TPM FDE and youāll only be able to run that command post install, if you canāt get that far something has gone wrong. Could you please file a bug against the project with your system info and setup and weāll look into why it might not work for you. Youāve done a lot of testing and it would be good to bank those learnings. I appreciate you exploring all the options.
As I said we plan to expand hardware support significanlty within the lifecycle of the LTS, currently we are prioritising NVIDIA driver support. I think we can improve some of the messaging in the installer as well, Iāll add that to our backlog.
I donāt know if this has been brought up before, but Iād like to access the encrypted partition when I boot another operating system like the Ubuntu ISO or Fedora. With standard LUKS partitions you can just add another key / passphrase to a slot in LUKS. But I failed getting this to work today on a test system.
# Add another key while running from /dev/nvme0n1p4
sudo cryptsetup luksAddKey --token-type systemd-tpm2 /dev/nvme0n1p4
# Attempt to unlock from Ubuntu Installation Media
sudo cryptsetup open /dev/nvme0n1p4 test
It didnāt accept the key I set before. With this being a test system and to rule out any mistyping I set the additional passphrase to 123456 and it didnāt work. Of course I also tried it in Gnome Disks and it didnāt work there either.
Side note: After all my struggles I can now install TPM-backed encryption on my laptops without hassle. I just reset the security chip and set secure boot keys to factory defaults. I have no idea why it was so difficult before.
The recovery key you get from snapd doesnāt directly function as a luks key to unlock the drive. There is some format wizardry which converts it on-the-fly when you type it in at the prompt.
However, there is a way to get a working key-file to unlock your drives.
A user online wrote a GO script which can convert the recovery-key string to a working luks key-file: https://lemmy.world/post/7029429