snapd

FDE is still unreliable on UC22

Bug #2063113 reported by Viktor Petersson
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
snapd
Triaged
High
Valentin David

Bug Description

This is a follow up to:
https://bugs.launchpad.net/snapd/+bug/1953632

We're back again trying to get FDE working. This time on Ubuntu Core 22. So far it still doesn't look promising. We're exploring various boards for our next generation hardware platform. The first one I'm evaluating is the one I would expect to work out-of-the-box (as it's mostly "open"), namely Star Labs System's Byte Mk 2.

Here are some debugging data based on the previous ticket:

$ ls -lah /dev/tpm0
crw-rw---- 1 tss root 10, 224 Apr 22 12:30 /dev/tpm0

$ cat /sys/class/tpm/tpm*/tpm_version_major
2

$ sudo ./tcglog-check
open /sys/kernel/security/tpm0/binary_bios_measurements: no such file or directory

Revision history for this message
Viktor Petersson (vpetersson) wrote :
Revision history for this message
Valentin David (valentin.david) wrote :

What is the output of "findmnt --submounts /sys"?

Revision history for this message
Valentin David (valentin.david) wrote :

Also the output of "udevadm info /sys/class/tpm/tpm0/device"

Revision history for this message
Viktor Petersson (vpetersson) wrote :

Hi Valentin,

Sure thing:

$ findmnt --submounts /sys
TARGET SOURCE FSTYPE OPTIONS
/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/security securityfs securityfs rw,nosuid,nodev,noexec,relatime
├─/sys/fs/cgroup cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot
├─/sys/fs/pstore pstore pstore rw,nosuid,nodev,noexec,relatime
├─/sys/firmware/efi/efivars efivarfs efivarfs rw,nosuid,nodev,noexec,relatime
├─/sys/fs/bpf bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700
├─/sys/kernel/debug debugfs debugfs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/tracing tracefs tracefs rw,nosuid,nodev,noexec,relatime
├─/sys/fs/fuse/connections fusectl fusectl rw,nosuid,nodev,noexec,relatime
└─/sys/kernel/config configfs configfs rw,nosuid,nodev,noexec,relatime

$ udevadm info /sys/class/tpm/tpm0/device
P: /devices/LNXSYSTM:00/LNXSYBUS:00/MSFT0101:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/MSFT0101:00
E: DRIVER=tpm_crb
E: MODALIAS=acpi:MSFT0101:MSFT0101:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=7452148
E: ID_VENDOR_FROM_DATABASE=M-Systems Flash Disk Pioneers

Revision history for this message
Valentin David (valentin.david) wrote :

Is that machine using coreboot + edk2? Was the edk2 payload built with secure boot enabled?

Another common thing is wrong ACPI tables. It would be nice to get the journal output to see where the kernel failed.

What image did you test? Was it a stable build of UC22 for x86-64? Do you know which version of pc-kernel it is using?

Revision history for this message
Viktor Petersson (vpetersson) wrote :

To add to this, we have a second device now that is behaving the same way. This device I would also expect to "just work" as it's a regular NUC (NUC13ANBi3), which should be supported by FDE on Core 22.

Debug output from this device:

$ ls -lah /dev/tpm0
crw-rw---- 1 tss root 10, 224 Apr 23 19:30 /dev/tpm0

$ cat /sys/class/tpm/tpm*/tpm_version_major
2

$ findmnt --submounts /sys
TARGET SOURCE FSTYPE OPTIONS
/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/security securityfs securit rw,nosuid,nodev,noexec,relatime
├─/sys/fs/cgroup cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime,n
├─/sys/fs/pstore pstore pstore rw,nosuid,nodev,noexec,relatime
├─/sys/firmware/efi/efivars efivarfs efivarf rw,nosuid,nodev,noexec,relatime
├─/sys/fs/bpf bpf bpf rw,nosuid,nodev,noexec,relatime,m
├─/sys/kernel/tracing tracefs tracefs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/debug debugfs debugfs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/config configfs configf rw,nosuid,nodev,noexec,relatime
└─/sys/fs/fuse/connections fusectl fusectl rw,nosuid,nodev,noexec,relatime

$ udevadm info /sys/class/tpm/tpm0/device
P: /devices/LNXSYSTM:00/LNXSYBUS:00/MSFT0101:00
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/MSFT0101:00
E: DRIVER=tpm_crb
E: MODALIAS=acpi:MSFT0101:
E: SUBSYSTEM=acpi
E: USEC_INITIALIZED=11635477
E: ID_VENDOR_FROM_DATABASE=M-Systems Flash Disk Pioneers

$ sudo dmsetup ls --target crypt
No devices found

$ sudo blkid
/dev/loop1: TYPE="squashfs"
/dev/nvme0n1p5: LABEL="ubuntu-data" UUID="72f553b9-b48b-412a-9839-c0f1a4fdbe27" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-data" PARTUUID="32f23f52-9534-f849-9a13-bd8d20a822ab"
/dev/nvme0n1p3: LABEL="ubuntu-boot" UUID="1a8e53a3-2767-455b-8536-0a7aed02c05c" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-boot" PARTUUID="608ddc38-3b53-7a45-873a-a96db0c0bd1e"
/dev/nvme0n1p1: PARTLABEL="BIOS Boot" PARTUUID="16c60cce-4701-450b-98ce-5404f1897d64"
/dev/nvme0n1p4: LABEL="ubuntu-save" UUID="643db19f-3f7f-4654-9aa5-b38f9408f2c4" BLOCK_SIZE="1024" TYPE="ext4" PARTLABEL="ubuntu-save" PARTUUID="186cbb18-1c14-d94f-92c9-6700fc69b3d0"
/dev/nvme0n1p2: LABEL_FATBOOT="ubuntu-seed" LABEL="ubuntu-seed" UUID="312B-9570" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ubuntu-seed" PARTUUID="5ab39fc7-7088-451b-8db7-ea97e710e9af"
/dev/loop4: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"

For both these devices, we used the upstream amd64 image (which should have 'prefer-encryption' set by default I believe).

Revision history for this message
Viktor Petersson (vpetersson) wrote (last edit ):

Looks like the wires crossed. :)

> Is that machine using coreboot + edk2? Was the edk2 payload built with secure boot enabled?

We're using the upstream amd64 image to rule out any disk image errors (https://cdimage.ubuntu.com/ubuntu-core/22/stable/current/ubuntu-core-22-amd64.img.xz).

> Another common thing is wrong ACPI tables. It would be nice to get the journal output to see where the kernel failed.

Sure - here's the full output from `journalctl`:
https://gist.github.com/vpetersson/3ed08452bb1ee930c2fcf322705be34f

> What image did you test? Was it a stable build of UC22 for x86-64? Do you know which version of pc-kernel it is using?

As mentioned, it's the upstream image.

Here's the list of snaps (after a `snap refresh` once though).

$ sudo snap list
Name Version Rev Tracking Publisher Notes
core22 20240408 1380 latest/stable canonical✓ base
pc 22-0.3 146 22/stable canonical✓ gadget
pc-kernel 5.15.0-105.115.1 1781 22/stable canonical✓ kernel
snapd 2.62 21465 latest/stable canonical✓ snapd

Revision history for this message
Valentin David (valentin.david) wrote :

Is /sys/kernel/security/tpm0/binary_bios_measurements missing also on the NUC?

I have tried the image on a NUC10i7FNB and it worked.

Also, could you look if the tpm has a lockout? Do this and give the output.

sudo snap install tpm2-tools-alexmurray
sudo snap connect tpm2-tools-alexmurray:tpm
sudo tpm2-tools-alexmurray.getcap properties-variable

If it has a lockout from another previously installed OS, then install may fail and install without tpm.

To reset the tpm you have to do

echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request

Then you have to reboot. You can force reinstall by rebooting with this command:

sudo snap reboot --install

For the Star Labs System's Byte Mk 2, could you give the content of all the /sys/devices/virtual/dmi/id/bios_* ?

Revision history for this message
Viktor Petersson (vpetersson) wrote (last edit ):
Download full text (3.8 KiB)

For context - both of these systems should be brand new. To my knowledge, no other OS has been installed on either of them.

> Is /sys/kernel/security/tpm0/binary_bios_measurements missing also on the NUC?

I need to wait until later today when my colleague wakes up to check that.

> Also, could you look if the tpm has a lockout? Do this and give the output.

Sure - this is the output from the Star Labs System device:

$ sudo snap install tpm2-tools-alexmurray
tpm2-tools-alexmurray 5.3 from Alex Murray (alexmurray✪) installed

$ sudo snap connect tpm2-tools-alexmurray:tpm

$ sudo tpm2-tools-alexmurray.getcap properties-variable
TPM2_PT_PERMANENT:
  ownerAuthSet: 0
  endorsementAuthSet: 0
  lockoutAuthSet: 0
  reserved1: 0
  disableClear: 0
  inLockout: 0
  tpmGeneratedEPS: 0
  reserved2: 0
TPM2_PT_STARTUP_CLEAR:
  phEnable: 1
  shEnable: 1
  ehEnable: 1
  phEnableNV: 1
  reserved1: 0
  orderly: 1
TPM2_PT_HR_NV_INDEX: 0x0
TPM2_PT_HR_LOADED: 0x0
TPM2_PT_HR_LOADED_AVAIL: 0x3
TPM2_PT_HR_ACTIVE: 0x0
TPM2_PT_HR_ACTIVE_AVAIL: 0x40
TPM2_PT_HR_TRANSIENT_AVAIL: 0x3
TPM2_PT_HR_PERSISTENT: 0x0
TPM2_PT_HR_PERSISTENT_AVAIL: 0x15
TPM2_PT_NV_COUNTERS: 0x0
TPM2_PT_NV_COUNTERS_AVAIL: 0x4
TPM2_PT_ALGORITHM_SET: 0x0
TPM2_PT_LOADED_CURVES: 0x4
TPM2_PT_LOCKOUT_COUNTER: 0x0
TPM2_PT_MAX_AUTH_FAIL: 0x20
TPM2_PT_LOCKOUT_INTERVAL: 0x1C20
TPM2_PT_LOCKOUT_RECOVERY: 0x15180
TPM2_PT_NV_WRITE_RECOVERY: 0x0
TPM2_PT_AUDIT_COUNTER_0: 0x0
TPM2_PT_AUDIT_COUNTER_1: 0x0

$ echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request
5

$ cat /sys/devices/virtual/dmi/id/bios_*
04/19/2024
24.2
coreboot
24.04

$ sudo snap reboot --install

[wait for the device to be re-instated]

$ findmnt --submounts /sys
TARGET SOURCE FSTYPE OPTIONS
/sys sysfs sysfs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/security securityfs securityfs rw,nosuid,nodev,noexec,relatime
├─/sys/fs/cgroup cgroup2 cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot
├─/sys/fs/pstore pstore pstore rw,nosuid,nodev,noexec,relatime
├─/sys/firmware/efi/efivars efivarfs efivarfs rw,nosuid,nodev,noexec,relatime
├─/sys/fs/bpf bpf bpf rw,nosuid,nodev,noexec,relatime,mode=700
├─/sys/kernel/debug debugfs debugfs rw,nosuid,nodev,noexec,relatime
├─/sys/kernel/tracing tracefs tracefs rw,nosuid,nodev,noexec,relatime
├─/sys/fs/fuse/connections fusectl fusectl rw,nosuid,nodev,noexec,relatime
└─/sys/kernel/config configfs configfs rw,nosuid,nodev,noexec,relatime

$ sudo blkid
/dev/loop1: TYPE="squashfs"
/dev/nvme0n1p5: LABEL="ubuntu-data" UUID="4b2c84bc-d101-4876-a974-5facbb5af775" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-data" PARTUUID="52025746-fc3d-c24e-b094-26f721c7cd48"
/dev/nvme0n1p3: LABEL="ubuntu-boot" UUID="5a2c439c-cf62-4773-8376-2603ea7a81fe" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-boot" PARTUUID="7206e296-fce4-924c-b6fd-affe...

Read more...

Revision history for this message
Valentin David (valentin.david) wrote :

For the Star Labs System, I think this is an issue with the firmware. I do not think the lockout is the issue.

Could you give the output of the following commands on the Star Labs System?

sudo cat /sys/firmware/acpi/tables/TPM2 | basenc --base16
cat /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c | basenc --base16

Revision history for this message
Viktor Petersson (vpetersson) wrote :

Sure thing:

$ sudo cat /sys/firmware/acpi/tables/TPM2 | basenc --base16
54504D324C00000004C8434F52457634434F5245424F4F5400000000434F5245280623200000
00004000D4FE00000000070000000000000000000000000000000000010000D09B7600000000

$ cat /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c | basenc --base16
cat: /sys/firmware/efi/efivars/SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c: No such file or directory

$ ls /sys/firmware/efi/efivars/
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f OsIndicationsSupported-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c LoaderFirmwareInfo-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c
Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c LoaderFirmwareType-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c HwErrRecSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c LoaderImageIdentifier-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f PlatformRecovery0000-8be4df61-93ca-11d2-aa0d-00e098032b8c
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c Key0000-8be4df61-93ca-11d2-aa0d-00e098032b8c MTC-eb704011-1402-11d3-8e77-00a0c969723b SbatLevelRT-605dab50-e046-4300-abb6-3dd810dd8b23
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c Key0001-8be4df61-93ca-11d2-aa0d-00e098032b8c MokListRT-605dab50-e046-4300-abb6-3dd810dd8b23 StubInfo-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c MokListTrustedRT-605dab50-e046-4300-abb6-3dd810dd8b23 Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c MokListXRT-605dab50-e046-4300-abb6-3dd810dd8b23 VarErrorFlag-04b37fe8-f6ae-480b-bdd5-37d98c5e89aa

Revision history for this message
Valentin David (valentin.david) wrote :

It looks like the firmware on the Star Labs machine does not support secure boot. I wonder if it is a build of edk2 without secure boot and tpm2 enabled. Could you see if you can update the firmware with fwupd?

Revision history for this message
Viktor Petersson (vpetersson) wrote :

> It looks like the firmware on the Star Labs machine does not support secure boot. I wonder if it is a build of edk2 without secure boot and tpm2 enabled. Could you see if you can update the firmware with fwupd?

I'm 99% sure it does. In fact, it will not boot anything that isn't Secure Boot

Revision history for this message
Viktor Petersson (vpetersson) wrote :

Interesting:

$ sudo snap install test-snapd-mokutil --beta --devmode
test-snapd-mokutil (beta) 0.3.0 from Sergio Cazzolato (cachio) installed

$ test-snapd-mokutil --sb-state
This system doesn't support Secure Boot

Revision history for this message
Valentin David (valentin.david) wrote :

> In fact, it will not boot anything that isn't Secure Boot

I think it is probably booting only UEFI and it cannot boot legacy BIOS. But I do not think it boots in secure boot.

Since they claim it can do secure boot and measured boot on their website, I expect there are newer builds of the firmware that can do it.

Or maybe there is some firmware configuration. Have you tried to go in the settings menu of the firmware? Probably pressing ESC while booting.

Revision history for this message
Viktor Petersson (vpetersson) wrote :

Thanks, Valentin. I'm in conversation with the vendor and they are working on reproducing (and patching) the BIOS.

I'm also still awaiting the output from the other NUC.

Revision history for this message
Star Labs (starlabs) wrote :

To update from our end. The current coreboot build is built with SecureBoot disabled and hidden.

We have since verified on our reference AMI firmware that the hardware will allow an FDE with TPM deployment of Ubuntu core 22.

Now we know the requirements, we can adjust the coreboot firmware to requirements.

Philip Meulengracht (the-meulengracht)
Changed in snapd:
assignee: nobody → Valentin David (valentin.david)
status: New → Triaged
importance: Undecided → High
Revision history for this message
Viktor Petersson (vpetersson) wrote :

@Valintin - I think we can rule out the Star Labs device for this for now. Will chat with the guys over there on the best way to proceed.

In the meantime, here's the output from the first NUC:

```
$ ls -l /sys/kernel/security/tpm0/binary_bios_measurements
-r--r----- 1 root root 0 Apr 25 17:38 /sys/kernel/security/tpm0/binary_bios_measurements
```
```
$ sudo snap install tpm2-tools-alexmurray
tpm2-tools-alexmurray 5.3 from Alex Murray (alexmurray✪) installed
```
```
$ sudo snap connect tpm2-tools-alexmurray:tpm
```
```
$ sudo tpm2-tools-alexmurray.getcap properties-variable
TPM2_PT_PERMANENT:
  ownerAuthSet: 0
  endorsementAuthSet: 0
  lockoutAuthSet: 1
  reserved1: 0
  disableClear: 1
  inLockout: 0
  tpmGeneratedEPS: 0
  reserved2: 0
TPM2_PT_STARTUP_CLEAR:
  phEnable: 1
  shEnable: 1
  ehEnable: 1
  phEnableNV: 1
  reserved1: 0
  orderly: 1
TPM2_PT_HR_NV_INDEX: 0x3
TPM2_PT_HR_LOADED: 0x0
TPM2_PT_HR_LOADED_AVAIL: 0x3
TPM2_PT_HR_ACTIVE: 0x0
TPM2_PT_HR_ACTIVE_AVAIL: 0x40
TPM2_PT_HR_TRANSIENT_AVAIL: 0x3
TPM2_PT_HR_PERSISTENT: 0x3
TPM2_PT_HR_PERSISTENT_AVAIL: 0x12
TPM2_PT_NV_COUNTERS: 0x2
TPM2_PT_NV_COUNTERS_AVAIL: 0x4
TPM2_PT_ALGORITHM_SET: 0x0
TPM2_PT_LOADED_CURVES: 0x4
TPM2_PT_LOCKOUT_COUNTER: 0x0
TPM2_PT_MAX_AUTH_FAIL: 0x20
TPM2_PT_LOCKOUT_INTERVAL: 0x1C20
TPM2_PT_LOCKOUT_RECOVERY: 0x15180
TPM2_PT_NV_WRITE_RECOVERY: 0x0
TPM2_PT_AUDIT_COUNTER_0: 0x0
TPM2_PT_AUDIT_COUNTER_1: 0x0
```

Revision history for this message
Valentin David (valentin.david) wrote :

Yes, there is a lockout. There was probably another system using the TPM on this machine. Could you try to do the following?

echo 5 | sudo tee /sys/class/tpm/tpm0/ppi/request
sudo snap reboot --install

Revision history for this message
Viktor Petersson (vpetersson) wrote :

Here's the output from the various commands after the reset:

$ sudo blkid
/dev/loop1: TYPE="squashfs"
/dev/nvme0n1p5: LABEL="ubuntu-data" UUID="d751579d-4f5a-4292-9f7f-75b3a3ef40e5" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-data" PARTUUID="f9cdc648-3237-f240-adbf-27a04a35f971"
/dev/nvme0n1p3: LABEL="ubuntu-boot" UUID="e946a179-14a7-4af2-b151-2ff7220a66ec" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="ubuntu-boot" PARTUUID="46c44e68-a578-3e42-8205-2aaf7418b005"
/dev/nvme0n1p1: PARTLABEL="BIOS Boot" PARTUUID="16c60cce-4701-450b-98ce-5404f1897d64"
/dev/nvme0n1p4: LABEL="ubuntu-save" UUID="f9db7166-2b18-4442-9938-f2b31f3d555a" BLOCK_SIZE="1024" TYPE="ext4" PARTLABEL="ubuntu-save" PARTUUID="905e9a27-7173-1c46-ba05-88653f6c9dd7"
/dev/nvme0n1p2: LABEL_FATBOOT="ubuntu-seed" LABEL="ubuntu-seed" UUID="312B-9570" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="ubuntu-seed" PARTUUID="5ab39fc7-7088-451b-8db7-ea97e710e9af"
/dev/loop4: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop0: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"

$ sudo dmsetup ls --target crypt
No devices found

$ lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
NAME SIZE TYPE MOUNTPOINT
loop0 74.2M loop /snap/core22/1122
loop1 1.6M loop /snap/pc/146
loop2 296.3M loop /snap/pc-kernel/1781
loop3 334.8M loop /snap/pc-kernel/1646
loop4 40.4M loop /snap/snapd/20671
nvme0n1 238.5G disk
├─nvme0n1p1 1M part
├─nvme0n1p2 1.2G part /var/lib/snapd/seed
├─nvme0n1p3 750M part /run/mnt/ubuntu-boot
├─nvme0n1p4 32M part /var/lib/snapd/save
└─nvme0n1p5 236.5G part /writable

$ ls -l /sys/kernel/security/tpm0/binary_bios_measurements
-r--r----- 1 root root 0 May 1 13:08 /sys/kernel/security/tpm0/binary_bios_measurements

$ sudo snap install tpm2-tools-alexmurray
tpm2-tools-alexmurray 5.3 from Alex Murray (alexmurray✪) installed

$ sudo snap connect tpm2-tools-alexmurray:tpm
$ sudo tpm2-tools-alexmurray.getcap properties-variable
TPM2_PT_PERMANENT:
  ownerAuthSet: 0
  endorsementAuthSet: 0
  lockoutAuthSet: 1
  reserved1: 0
  disableClear: 1
  inLockout: 0
  tpmGeneratedEPS: 0
  reserved2: 0
TPM2_PT_STARTUP_CLEAR:
  phEnable: 1
  shEnable: 1
  ehEnable: 1
  phEnableNV: 1
  reserved1: 0
  orderly: 1
TPM2_PT_HR_NV_INDEX: 0x2
TPM2_PT_HR_LOADED: 0x0
TPM2_PT_HR_LOADED_AVAIL: 0x3
TPM2_PT_HR_ACTIVE: 0x0
TPM2_PT_HR_ACTIVE_AVAIL: 0x40
TPM2_PT_HR_TRANSIENT_AVAIL: 0x3
TPM2_PT_HR_PERSISTENT: 0x2
TPM2_PT_HR_PERSISTENT_AVAIL: 0x13
TPM2_PT_NV_COUNTERS: 0x2
TPM2_PT_NV_COUNTERS_AVAIL: 0x4
TPM2_PT_ALGORITHM_SET: 0x0
TPM2_PT_LOADED_CURVES: 0x4
TPM2_PT_LOCKOUT_COUNTER: 0x0
TPM2_PT_MAX_AUTH_FAIL: 0x20
TPM2_PT_LOCKOUT_INTERVAL: 0x1C20
TPM2_PT_LOCKOUT_RECOVERY: 0x15180
TPM2_PT_NV_WRITE_RECOVERY: 0x0
TPM2_PT_AUDIT_COUNTER_0: 0x0
TPM2_PT_AUDIT_COUNTER_1: 0x0

From what I can gather based on the output, FDE did not kick in.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.