TPM/FDE progress for Ubuntu 25.10

Guys, I’m testing the daily build of 25.10, 09.18.2025 on HP EliteBook 860 G11 and faced two challenges.

  1. It is necessary to enable the MS UEFI CA Key in the UEFI/BIOS settings.

Otherwise, the Secure Boot setup fails during the setup process.
2. At the encryption select step, I can’t select HW FDE because of Intel BootGuard configuration, but it is hardware-enforced, and I can’t configure it in the HP UEFI/BIOS settings menu.

  1. The best I can do is “Restore Security Settings to Factory Default”.

In this case, it will also reset TPM, Fingerprint, and Absolute Persistence Module.
For the HP EliteBook 850 G8,
This action is enough, but not in this case.
Are there any suggestions?

Hey! Thanks for letting us know!

Do you mind opening a bug on launchpad against snapd and reference it here? That way, we can track and act on it accordingly. Thanks!

Hi @didrocks! I just tested out 25.10 beta along with previous daily builds and I am still having issues on amd/intel devices (from lenovo and asus respectively )which seems to be a regressions compared to 25.04

The launchpad bug has links attached for your reference regarding my previous discussion of this issue. If you need more info let me know

Sorry, I’m new to Launchpad, can’t find snapd, so created this one:

I think GitHub will be better, but I have no Idea where to open the bug report:
in:

or better in:

I think snapd works well and the issue must be in secboot?

Thanks! I have retargeted it against snapd (snapd is using launchpad instead of github issue tracker) and subscribe Chris to have a look at it.

Yeah, this is secboot that is doing those checks, which is a go package used and vendored by snapd.

2 Likes

I tried to install Ubuntu 25.10 Beta to Framework 13 Ryzen 300 and I see error about TPM:

not encrypting device storage as checking TPM gave: error with system security: unsupported platform: checking host security is not yet implemented for AMD

Do you need some additional diagnostics?

2 Likes

Yes! Some tooling and call for testing under preparation, slightly post-release.

2 Likes

What would be super cool is if the security centre could escrow the recovery key away to somewhere like Landscape. Then admins would have a centralised way to pull recovery keys like Bitlocker does.

2 Likes

Since many companies managing Windows and macOS via Intune and save recovery keys in Entra ID, I think this is must have functionality.
It can be realized via CLI command or via synchronization between Landscape and Entra ID via Intune portal.

1 Like

Couldn’t agree more. The lack of an escrow the recovery key is why we can’t implement Ubuntu on a laptops at my company. I’ve been testing a couple of ways to save keys to various Vaults or Active Directory attributes by running scripts manually but it isn’t suitable for corporate environments. I’m looking forward to this feature in 26.04 LTS

2 Likes

+1 for escrow. This is basically what I was hinting at in my previous reply.

For now, we’re using some custom python scripts to generate recovery keys during autoinstall and then POST them back to one of our management systems.

Of course, something a bit more integrated would be great.

2 Likes

Would you be able to expand a little on our solution? I’m having the same issue - managing a fleet of ~100 clients and need to start of rollout of FDE. So the intune/landscape integrations is crucial but my guess Is that it will take some time… Until then I need to integrate something custom in my PXE-based provisioning flow…

1 Like

@david-boman-cpac It’s pretty bespoke, but I’m happy to share what I can.

We’re using Ubuntu Autoinstall in a customised Ubuntu USB installer.

Here’s a high-level overview of our autoinstall:

  1. Use early-commands section to generate a LUKS passphrase. We use a function built into our python script, but you could just as easily do a one-liner like openssl rand -base64 16 > /tmp/luks_passphrase
  2. Configure Ubuntu with autoinstall but use a custom storage layout. I couldn’t see any way to use the premade storage layouts with a specified LUKS passphrase file. You can only specify a single LUKS passphrase here, so if you need more that needs to be done in late-commands section.
  3. During late-commands section we run our python scripts to add an additional LUKS passphrase to the volume.
  4. We also use another script which will POST both the LUKS passphrases back to our Foreman orchestration server as host parameters.

I can’t share the raw scripts, but if you’re interested I can try to redact some stuff.

#cloud-config
autoinstall:
  version: 1
  early-commands:
    - /cdrom/custom/resources/luks_recovery.py generate-keyfile --path /tmp/luks_admin_passphrase --key-length 21
  locale: en_GB.UTF-8
  keyboard:
    layout: gb
  kernel:
    flavor: hwe
  drivers:
    install: true
  network:
    version: 2
    ethernets:
      all-en:
        match:
          name: en*
        dhcp4: true
      all-eth:
        match:
          name: eth*
        dhcp4: true
  identity:
    hostname: unassigned-hostname
    username: administrator
    realname: Local Admin
    password: 'xxxxxxxxxxxxxxxxxxxxxxxxxxx'
  ssh:
    install-server: true
    authorized-keys: []
    allow-pw: true
  storage:
    config:
    - type: disk
      id: disk-primary
      ptable: gpt
      match:
        size: largest
    - type: partition
      id: partition-1
      device: disk-primary
      number: 1
      size: 1G
      wipe: superblock
      preserve: false
      flag: boot
      grub_device: true      
    - type: format
      id: format-efi
      fstype: fat32
      volume: partition-1      
    - type: partition
      id: partition-2
      device: disk-primary
      number: 2
      size: 3G
      wipe: superblock
      preserve: false      
    - type: format
      id: format-boot
      fstype: ext4
      volume: partition-2
      preserve: false
    - type: partition
      id: partition-3
      device: disk-primary
      number: 3
      size: -1
      wipe: superblock
      preserve: false
    - type: dm_crypt
      id: dm_crypt-0
      volume: partition-3
      keyfile: /tmp/luks_admin_passphrase
      path: /dev/mapper/dm_crypt-0
      preserve: false
    - type: lvm_volgroup
      id: lvm_volgroup-0
      name: vg00
      devices:
        - dm_crypt-0
      preserve: false
    - type: lvm_partition
      id: lvm_partition-1
      name: root
      volgroup: lvm_volgroup-0
      size: -1
      wipe: superblock
      preserve: false
    - type: format
      id: format-root
      fstype: ext4
      volume: lvm_partition-1
      preserve: false
    - type: mount
      id: mount-root
      path: /
      device: format-root
    - type: mount
      id: mount-boot
      path: /boot
      device: format-boot
    - type: mount
      id: mount-efi
      path: /boot/efi
      device: format-efi
  packages:
    - ubuntu-desktop-minimal
  user-data:
    timezone: Europe/London
  late-commands:
    - rsync -vr /cdrom/custom/resources /target/tmp/
    - cp /tmp/luks_admin_passphrase /target/tmp/luks_admin_passphrase
    - curtin in-target -- cp /tmp/resources/PuppetCA.crt /usr/local/share/ca-certificates/
    - curtin in-target -- update-ca-certificates
    - curtin in-target -- /tmp/resources/new-hostname.sh
    - curtin in-target -- /tmp/resources/puppetizing.sh
    - curtin in-target -- /tmp/resources/provisioning.sh
    - curtin in-target -- /tmp/resources/luks_recovery.py --logfile /var/log/installer/luks_recovery.log add-key --key-file /tmp/luks_admin_passphrase --escrow /tmp/luks_user_passphrase
    - curtin in-target -- /tmp/resources/luks_recovery.py --logfile /var/log/installer/luks_recovery.log backup-headers --outfile /boot/luks_headers.back
    - curtin in-target -- /tmp/resources/foreman_create_workstation.py --recovery_keyfile /tmp/luks_admin_passphrase --recovery_keyfile /tmp/luks_user_passphrase

1 Like

Thanks, this is really helpful. In terms of provisioning I’m doing something similar (except FDE) but based on PXE instead of USB. Being a FDE/luks/exncryption noob … is the /tmp/luks_admin_passphrase they key do (stored in TPM?) for decryption. What about the recovery key? I see luks_recovery.py - is that your own code or something shipped with luks? Any scripts, redacted, is highly appreciated - I’m not looking for a complete solution but rather good archtictual ideas end examples to build upon.

Above example is just bog-standard LUKS encryption for the entire root partition (effectively FDE) with 2 passphrases. No TPM involved in this setup, just a separate disk encryption passphrase at startup.

TPM-FDE is still experimental and the autoinstall process is very hands-off. I think you can only configure it with one of the automatic storage layouts.
I never found a good way to extract the recovery key at deployment time for escrow.

I can send a PM with the script content, but I probably it’s not entirely relevant for your use-case.

Tested in on final release of Ubuntu 25.10. During install the option was greyed out, could not use TPM. Having dual-boot with windows, so TPM is enabled. Computer: asus zephyrus g16

fwupdmgr shows Linux kernel tainted Is that normal on a new install?
Is there a option to retry to use the TPM after installation?

Thanks

fwupdmgr security
Host Security ID: HSI:3! (v2.0.16)

HSI-1
✔ BIOS firmware updates:         Enabled
✔ MEI key manifest:              Valid
✔ MEI manufacturing mode:        Locked
✔ csme18 override:               Locked
✔ csme18 v0:18.0.5.2141:         Valid
✔ Platform debugging:            Disabled
✔ SPI write:                     Disabled
✔ SPI lock:                      Enabled
✔ SPI BIOS region:               Locked
✔ Supported CPU:                 Valid
✔ TPM empty PCRs:                Valid
✔ TPM v2.0:                      Found
✔ UEFI bootservice variables:    Locked
✔ UEFI platform key:             Valid
✔ UEFI secure boot:              Enabled

HSI-2
✔ Intel BootGuard ACM protected: Valid
✔ Intel BootGuard:               Enabled
✔ Intel BootGuard OTP fuse:      Valid
✔ IOMMU:                         Enabled
✔ Platform debugging:            Locked
✔ TPM PCR0 reconstruction:       Valid

HSI-3
✔ CET Platform:                  Supported
✔ Pre-boot DMA protection:       Enabled
✔ Suspend-to-idle:               Enabled
✔ Suspend-to-ram:                Disabled

HSI-4
✔ SMAP:                          Enabled
✘ Encrypted RAM:                 Disabled

Runtime Suffix -!
✔ CET OS Support:                Supported
✔ fwupd plugins:                 Untainted
✔ Linux kernel lockdown:         Enabled
✔ UEFI db:                       Valid
✘ Linux swap:                    Unencrypted
✘ Linux kernel:                  Tainted

Completely normal. That just means it uses build flags other than the defaults. You’ll find this in every Linux distribution.

Thanks for your confirmation. But do you see a reason from this why TPM was not supported during install? Do you know if I can try to activate TPM key store once Ubuntu is installed?