From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id C4997AC1222 for ; Tue, 16 Jan 2024 11:05:58 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=Ik0mPoLsBTTCHDo6pOGdP56dKoRcVsCp94lONcD/E8o=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:References:From:Cc:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1705403157; v=1; b=F6FQIbJ0Cd2ngw1tYAkFWpOFAU5Nokr/GjusBId6cR8SVCHbmJ4a5vkiz8Zr7oefHF9HiIAE VPfIFv44Dgti6mRXn4J6WyYNqL4/+gC7FsHDhDBYSR59u7+fynx0eMAIhU3i7s3PyDIVAdOnDzE lXWo0cP20dHQg7kTVeoNSzSY= X-Received: by 127.0.0.2 with SMTP id Lvr2YY7687511xefhrNBmeuG; Tue, 16 Jan 2024 03:05:57 -0800 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.10816.1705403156769773131 for ; Tue, 16 Jan 2024 03:05:56 -0800 X-Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-464-lg7UTqu2N--fJjl2D8JB3A-1; Tue, 16 Jan 2024 06:05:54 -0500 X-MC-Unique: lg7UTqu2N--fJjl2D8JB3A-1 X-Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 21BD61C05AE2; Tue, 16 Jan 2024 11:05:54 +0000 (UTC) X-Received: from [10.39.194.248] (unknown [10.39.194.248]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 770EB40C6EB9; Tue, 16 Jan 2024 11:05:53 +0000 (UTC) Message-ID: <2e13e25b-4cad-0735-a166-d340fe9bc5c4@redhat.com> Date: Tue, 16 Jan 2024 12:05:52 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] When TPM is enabled, Ubuntu doesn't boot To: hckaraca99@gmail.com References: <31929.1705322066913123785@groups.io> From: "Laszlo Ersek" Cc: "Yao, Jiewen" , edk2-devel-groups-io In-Reply-To: <31929.1705322066913123785@groups.io> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: CnMgwwzlrTjFqnBXMOO1S7t2x7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=F6FQIbJ0; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io 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 =3D 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 > 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 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 (=3D 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 (=3D 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 > 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 b= oot > path instead of the boot option we create. To avoid the infinite rese= t > 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 > > This is a backport from devel of: > > commit da6284569c4b5d60d14e6187f696f54cccb7b3d2 > Author: Gary Lin > 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 def= ault boot > path instead of the boot option we create. To avoid the infinit= e reset > loop, this commit introduce a countdown screen before fallback = resets the > system, so the user can interrupt the system reset and choose t= o boot > the restored boot option. The "Always continue boot" option cre= ates a > BS+RT+NV variable, FB_NO_REBOOT, to make fallback boot the firs= t boot > option afterward without asking. The user can revert the behavi= or by > removing the variable. > > https://github.com/rhboot/shim/issues/128 > > Signed-off-by: Gary Lin > > Signed-off-by: Peter Jones 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 > 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/19225= 81 > > Signed-off-by: Dimitri John Ledkov 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 - download "shim_15.7-0ubuntu1.debian.tar.xz" - extract the package - open "debian/rules" - find FALLBACK_NONINTERACTIVE=3D1 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 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- 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/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-