[Bug 2061551] [NEW] Merely booting Ubuntu 24.04 beta live CD breaks BitLocker & booting anything using Shim
Ratchanan Srirattanamet
2061551 at bugs.launchpad.net
Mon Apr 15 14:11:22 UTC 2024
Public bug reported:
On my ASUS Transformer Mini T103HAF, it seems like the dbx in Ubuntu
24.04 is too big or something, it breaks TPM's PCR7 measurement. And
since secureboot-db.service runs in a live CD, simply booting one will
apply this dbx. This causes BitLocker in the existing Windows
installation to fails to unlock & require recovery key.
Step to reproduce:
1. Boot into pre-installed Windows installation. Run "msinfo32.exe" as administrator, go to "System Summary", and verify that "PCR7 Configuration" is shown as "Bound".
2. Before proceed further, make sure that you have BitLocker recovery key available (or have it suspended). I have one backed up in Microsoft Account [1], or I think you can also open a terminal as administrator and run `manage-bde -protectors -get "C:"`.
3. Restart the machine into USB flashed with Ubuntu 24.04 live CD. You don't have to finish setting up language, keyboard layout etc.; you can restart the system as soon as a GUI appear. By that point, "secureboot-db.service" should have run.
4. Boot back to Windows. At this point, Windows will fail to boot asking for BitLocker recovery key. Input the key you have from step 2. After that, the system will reboot itself again.
5. Run "msinfo32.exe" as administrator again. Go to "System Summary", and notice that "PCR7 Configuration" is now shown as "Binding not possible".
6. Restart into the live USB again. This time, it won't boot, failing with:
```
Could not create MokListRT: Volume full
Could not create MokListXRT: Volume full
Could not create SbatlevelRT: Volume full
Could not create MokListTrustedRT: Volume full
Something has gone seriously wrong: import_mok_state() failed : Volume Full
```
And shortly after that, the machine turns off.
[1]: https://account.microsoft.com/devices/recoverykey
---
Now, to verify that dbx is indeed the source of the problem, I did the
following:
1. Reboot the system to the UEFI settings, go to Security > Secure Boot > Key Management, select Forbidden Signature > Set new key > Yes (restore to factory).
2. Reboot to Windows again. It will probably ask for BitLocker recovery key again. But once booted, run "msinfo32.exe" as administrator, go to "System Summary". "PCR7 Configuration" is now shown as "Bound" again.
3. Reboot into live USB again. This time it will boot. For debugging purpose, go to terminal and run `sudo mokutil --set-verbosity true`. Reboot to live USB.
4. Shim will now prints verbose message. Because I can't screencapture the boot process, I can't really transcribe the whole log to text (and my photo is of low quality). However, there are repeating lines along the line of (by now I'm using another Shim binary from Fedora 39 boot USB):
```
mok.c:798:mirror_one_mok_variable() tpm_log_event(0x73207F18, 76, 14, "MokListX")->Volume Full
Could not create MokListXRT: Volume Full
mok.c:926:import_one_mok_state() returning Volume Full
```
Or:
```
mok.c:762:mirror_one_mok_variable() tpm_measure_variable("SbatLevel",46,0x73207F98)->Volume Full
Could not create SbatLevelRT: Volume Full
mok.c:926:import_one_mok_state() returning Volume Full
```
---
I think there might be 2 problems that has to both be solved:
1. The dbx update causes breakage to TPM measured boot on this particular firmware.
2. Shim considers failure in TPM measured boot to be fatal and refuses to boot at all (as oppose to Windows which will still at least boot even if it will have to ask for recovery key later on).
---
Information about my tablet:
Make & model: ASUS Transformer Mini T103HAF
Firmware (BIOS) make & version: American Megatrends Inc. T103HAF.309, 22/4/2019
TPM manufacturer: INTC
TPM manufacturer version: 2.0.5.3015
TPM specification version: 2.0
** Affects: secureboot-db (Ubuntu)
Importance: Undecided
Status: New
** Affects: shim-signed (Ubuntu)
Importance: Undecided
Status: New
** Also affects: shim-signed (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to secureboot-db in Ubuntu.
https://bugs.launchpad.net/bugs/2061551
Title:
Merely booting Ubuntu 24.04 beta live CD breaks BitLocker & booting
anything using Shim
Status in secureboot-db package in Ubuntu:
New
Status in shim-signed package in Ubuntu:
New
Bug description:
On my ASUS Transformer Mini T103HAF, it seems like the dbx in Ubuntu
24.04 is too big or something, it breaks TPM's PCR7 measurement. And
since secureboot-db.service runs in a live CD, simply booting one will
apply this dbx. This causes BitLocker in the existing Windows
installation to fails to unlock & require recovery key.
Step to reproduce:
1. Boot into pre-installed Windows installation. Run "msinfo32.exe" as administrator, go to "System Summary", and verify that "PCR7 Configuration" is shown as "Bound".
2. Before proceed further, make sure that you have BitLocker recovery key available (or have it suspended). I have one backed up in Microsoft Account [1], or I think you can also open a terminal as administrator and run `manage-bde -protectors -get "C:"`.
3. Restart the machine into USB flashed with Ubuntu 24.04 live CD. You don't have to finish setting up language, keyboard layout etc.; you can restart the system as soon as a GUI appear. By that point, "secureboot-db.service" should have run.
4. Boot back to Windows. At this point, Windows will fail to boot asking for BitLocker recovery key. Input the key you have from step 2. After that, the system will reboot itself again.
5. Run "msinfo32.exe" as administrator again. Go to "System Summary", and notice that "PCR7 Configuration" is now shown as "Binding not possible".
6. Restart into the live USB again. This time, it won't boot, failing with:
```
Could not create MokListRT: Volume full
Could not create MokListXRT: Volume full
Could not create SbatlevelRT: Volume full
Could not create MokListTrustedRT: Volume full
Something has gone seriously wrong: import_mok_state() failed : Volume Full
```
And shortly after that, the machine turns off.
[1]: https://account.microsoft.com/devices/recoverykey
---
Now, to verify that dbx is indeed the source of the problem, I did the
following:
1. Reboot the system to the UEFI settings, go to Security > Secure Boot > Key Management, select Forbidden Signature > Set new key > Yes (restore to factory).
2. Reboot to Windows again. It will probably ask for BitLocker recovery key again. But once booted, run "msinfo32.exe" as administrator, go to "System Summary". "PCR7 Configuration" is now shown as "Bound" again.
3. Reboot into live USB again. This time it will boot. For debugging purpose, go to terminal and run `sudo mokutil --set-verbosity true`. Reboot to live USB.
4. Shim will now prints verbose message. Because I can't screencapture the boot process, I can't really transcribe the whole log to text (and my photo is of low quality). However, there are repeating lines along the line of (by now I'm using another Shim binary from Fedora 39 boot USB):
```
mok.c:798:mirror_one_mok_variable() tpm_log_event(0x73207F18, 76, 14, "MokListX")->Volume Full
Could not create MokListXRT: Volume Full
mok.c:926:import_one_mok_state() returning Volume Full
```
Or:
```
mok.c:762:mirror_one_mok_variable() tpm_measure_variable("SbatLevel",46,0x73207F98)->Volume Full
Could not create SbatLevelRT: Volume Full
mok.c:926:import_one_mok_state() returning Volume Full
```
---
I think there might be 2 problems that has to both be solved:
1. The dbx update causes breakage to TPM measured boot on this particular firmware.
2. Shim considers failure in TPM measured boot to be fatal and refuses to boot at all (as oppose to Windows which will still at least boot even if it will have to ask for recovery key later on).
---
Information about my tablet:
Make & model: ASUS Transformer Mini T103HAF
Firmware (BIOS) make & version: American Megatrends Inc. T103HAF.309, 22/4/2019
TPM manufacturer: INTC
TPM manufacturer version: 2.0.5.3015
TPM specification version: 2.0
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/secureboot-db/+bug/2061551/+subscriptions
More information about the foundations-bugs
mailing list