Re: [edk2-devel] When TPM is enabled, Ubuntu doesn't boot

["Laszlo Ersek" <lersek@redhat.com>]

On 1/15/24 13:34, Hamit Can Karaca wrote:
> Hi Yao, Jiewen,
> I actually tried to get help from the ubuntu people but they really
> don't understand what is going in the UEFI side. I am trying to fix
> this problem for 3 weeks now and I am about the give up. I hope
> somebody can help me :(

The log you attached up-thread ends like this:

> FSOpen: Open '\EFI\ubuntu\BOOTX64.CSV' Success
> Tcg2GetCapability ...
> Size - 0x24
>  1.1 - 0x24, 1.0 - 0x1C
> Tcg2GetCapability - Success
> Reset System
> PROGRESS CODE: V0311100A I0
> DXE ResetSystem2: ResetType Cold, Call Depth = 1.

this is consistent with the "shim" project's "fallback" utility
resetting your system, when the TPM is enabled. In particular, the
"Reset System" message is printed by "fallback.c".

For getting a more verbose log, you can try setting the FALLBACK_VERBOSE
UEFI variable:

- boot Ubuntu with the TPM disabled (for now)

- in a root shell, issue the following command:

  mokutil --set-fallback-verbosity true

- reboot (then reenable the TPM)

This would give us some extra insight into fallback's thinking /
process.

However, even without the verbose fallback log, we can speculate. In
particular, in the fallback code and commit log, I've found the
following commit:

> commit 431b8a2e75a71a0b1f47d47d3f045b1e3efbce53
> Author: Peter Jones <pjones@redhat.com>
> Date:   Mon Jul 31 13:10:41 2017 -0400
>
>     Make fallback aware of tpm measurements, and reboot if tpm is used.
>
>     Since booting the entry with fallback in the stack of things that got
>     measured will result in all the wrong PCR values, in the cases where TPM
>     is present and enabled, use ->Reset() instead of loading the Boot####
>     variable and executing its target.
>
>     Signed-off-by: Peter Jones <pjones@redhat.com>

The idea is that:

(1) you have an installed Ubuntu system

(2) for some reason, you don't have proper UEFI Boot#### options,
matching your installed Ubuntu OS.

(3) consequently, your platform firmware loads the default UEFI boot
loader, not a specific, designated OS boot loader

(4) it is actually "shim" that fills both roles (default / fallback boot
loader, and specific first stage OS boot loader too), however, shim
behaves differently, dependent on which role it is being invoked in. In
the former role, it invokes (IIUC) the "fallback" utility (also built
from the shim project).

(5) what the fallback utility does is that it tries to *recreate* your
missing UEFI Boot#### variables, and then *at once* proceed to booting
your Ubuntu OS. For the recreation of the variables, fallback looks at
the file "\EFI\ubuntu\BOOTX64.CSV", which is basically an alternative
(disk-based fallback) storage for boot option information. That's why
you see that file mentioned in the log; the file system driver reports
opening that file.

(6) Now, where I write "at once proceeds to booting your Ubuntu OS" is
where the TPM plays a part, and where the above-quoted commit is
relevant. The TPM measures the entire boot path, and if the boot path
changes, the values (= hash results) in the PCRs (platform config
registers) will not match those that the TPM expects. This means that
the TPM will not "unseal" secrets for you, such as a full disk (LUKS)
encryption key. Now, including the fallback utility in the boot process
is certainly a boot path change, so when fallback runs, and it detects
that a TPM is enabled (because it finds TPM-related UEFI protocols in
the protocol database), it *knows* that the TPM will "catch" the change
in the boot path. Therefore, after recreating the missing UEFI Boot####
variables (boot options), fallback decides to *reboot* -- i.e., relaunch
the boot path from zero. Because next time around, the just-recreated
Boot#### options should take effect (i.e., fallback should not be part
of the next boot path), and then TPM should be happy too.

(7) Your problem actually seems to be that the Boot#### option
recreation step fails! The *first* reset itself is fine and justified
(with the TPM enabled); the problem is that fallback is reached during
*next boot* again. That should not happen; the Boot#### options should
be in place by then.

Your platform firmware (= motherboard) may be busted by design. Some
platform vendors do not permit the modification of Boot#### options.
This is actually "platform policy", so it is not a UEFI spec violation
per se. But the end result is that "fallback" cannot modify Boot####
options, so it always try to re-create them, and always resets due to
the TPMs presence.

If you really want to enable the TPM, you might have to use the
"FB_NO_REBOOT" UEFI variable of shim. This is described in the following
shim commit:

> commit a5db51a52e8d4cae938fc807b991383309dffca7
> Author: Gary Lin <glin@suse.com>
> Date:   Wed May 23 18:13:05 2018 +0800
>
>     fallback: show a countdown menu before reset
>
>     Some machines with the faulty firmware may keep booting the default boot
>     path instead of the boot option we create. To avoid the infinite reset
>     loop, this commit introduce a countdown screen before fallback resets the
>     system, so the user can interrupt the system reset and choose to boot
>     the restored boot option. The "Always continue boot" option creates a
>     BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot
>     option afterward without asking. The user can revert the behavior by
>     removing the variable.
>
>     https://github.com/rhboot/shim/issues/128
>
>     Signed-off-by: Gary Lin <glin@suse.com>
>
>     This is a backport from devel of:
>
>       commit da6284569c4b5d60d14e6187f696f54cccb7b3d2
>       Author: Gary Lin <glin@suse.com>
>       Date:   Wed May 23 18:13:05 2018 +0800
>
>           fallback: show a countdown menu before reset
>
>           Some machines with the faulty firmware may keep booting the default boot
>           path instead of the boot option we create. To avoid the infinite reset
>           loop, this commit introduce a countdown screen before fallback resets the
>           system, so the user can interrupt the system reset and choose to boot
>           the restored boot option. The "Always continue boot" option creates a
>           BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the first boot
>           option afterward without asking. The user can revert the behavior by
>           removing the variable.
>
>           https://github.com/rhboot/shim/issues/128
>
>           Signed-off-by: Gary Lin <glin@suse.com>
>
>     Signed-off-by: Peter Jones <pjones@redhat.com>

Do you see the "Press any key to stop system reset" message?

Do you see the "Always continue boot" message?

... Ah, wait, looking at the fallback code leads me to another commit
that could be very relevant:

> commit 0837d010a6ee140ff3cc770aadc89fbb015a7ca2
> Author: Dimitri John Ledkov <xnox@ubuntu.com>
> Date:   Tue Apr 6 14:58:00 2021 +0100
>
>     fallback: add compile option FALLBACK_NONINTERACTIVE
>
>     In the cloud, all boots are non-interactive with keyboard and console
>     access either typically not available or prohibited. Also clouds
>     always do firstboot via fallback. This currently results in an
>     unacceptable 5s boot delay whilst fallback offers interactive reset
>     options that cannot be actioned.
>
>     In Ubuntu, we'd like to make fallback noninteractive by default
>     without any boot delays, due to bootspeed impact on firstboot of the
>     preinstalled images.
>
>     Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1922581
>
>     Signed-off-by: Dimitri John Ledkov <xnox@ubuntu.com>

So, the case seems to be:

- You have broken-by-design platform firmware (motherboard), which does
  not permit the external modification of Boot#### options.

- The FB_NO_REBOOT override is not available to you because (a) you use
  Ubuntu, and (b) Ubuntu builds their shim / fallback binaries with
  FALLBACK_NONINTERACTIVE: that is, with the override statically
  compiled out.

Evidence:

- go to <https://packages.ubuntu.com/mantic/shim>

- download "shim_15.7-0ubuntu1.debian.tar.xz"
  <http://archive.ubuntu.com/ubuntu/pool/main/s/shim/shim_15.7-0ubuntu1.debian.tar.xz>

- extract the package

- open "debian/rules"

- find FALLBACK_NONINTERACTIVE=1 in COMMON_OPTIONS

... Now, here's the final interesting bit. The scope of the
FALLBACK_NONINTERACTIVE macro in the shim source doesn't actually cover
the FB_NO_REBOOT *check*, it only covers the console menu where a user
can *set* FB_NO_REBOOT. Meaning, if you can find *any other way* to set
FB_NO_REBOOT, then you may still be able to avoid the reset.

Here's one idea:

- boot Ubuntu with the TPM disabled (for now)

- in a root shell, issue the following commands:

  mokutil --set-fallback-noreboot true
  mokutil --set-fallback-verbosity false

- reboot (then reenable the TPM)

Hope this helps,
Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113886): https://edk2.groups.io/g/devel/message/113886
Mute This Topic: https://groups.io/mt/103430908/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-