Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1333888
Summary: | shim in F24 needs upstream d01421eb5ae6 for working with grub 2.02-0.26 and later on AARCH64 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andrea Bolognani <abologna> |
Component: | shim-signed | Assignee: | Peter Jones <pjones> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 24 | CC: | bcl, lersek, lkundrak, mads, mjg59, mjuszkie, pbrobinson, pjones, rjones |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | aarch64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | shim-signed-0.8-9 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-05-21 20:27:50 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Andrea Bolognani
2016-05-06 14:45:37 UTC
Hi Andrea, the error message you quoted ("Failed to set MokListRT") comes from shim. I think that the shim package was upgraded as part of the F23 -> F24 transition. Also, since shim is a UEFI application, if it dances a fandango on core (NULL pointer deref and the like), that would be consistent with the symptom you are seeing (CPU exception caught and dumped by the edk2 exception handler). What are your shim package versions, before and after? CC'ing Peter. Anyway, the error message is printed when the MokListRT or MokListXRT UEFI variables cannot be set (with the SetVariable() runtime service). The EFI_INVALID_PARAMETER error code is specified for the following cases: * An invalid combination of attribute bits, name, and GUID was supplied, or the DataSize exceeds the maximum allowed. * VariableName is an empty string. Did you try installing an F24 guest from scratch? (Or maybe there's no released ISO yet, I don't know.) I reproduced the bug, using the exact same host-side components, and a practically identical guest configuration too. There was one important difference in my setup: instead of AAVMF_CODE.fd, I used AAVMF_CODE.verbose.fd, which is why I have a bit of additional information now, from the console: > Booting Fedora > FSOpen: Open '\EFI\fedora\shim.efi' Success > InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BA0238C0 > Loading driver at 0x000B85B6000 EntryPoint=0x000B85B6148 > Loading driver at 0x000B85B6000 EntryPoint=0x000B85B6148 > InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BA01EA58 > InstallProtocolInterface: 605DAB50-E046-4300-ABB6-3DD810DD8B23 B8652948 > Failed to set MokListRT: Invalid Parameter > FSOpen: Open '\EFI\fedora\grubaa64.efi' Success > > > Synchronous Exception at 0x00000000B83BE498 > > X0 0x1100069417FFFFE2 X1 0x00000000BBFF0018 X2 0x00000000B83C4C58 X3 0x00000000000FC400 > X4 0x0000000000000000 X5 0x0000000000000007 X6 0x00000000B9DEF018 X7 0x00000000BF1743A4 > X8 0x00000000BF1746E8 X9 0x00000000BF174A00 X10 0x000000000000003D X11 0x00000000000000B6 > X12 0x00000000700FE0FA X13 0x0000000000000000 X14 0x0000000000000000 X15 0x0000000000000000 > X16 0x00000000BF174C80 X17 0x0000000000000000 X18 0x0000000000000000 X19 0x00000000BBFF0018 > X20 0x0000000000000000 X21 0x00000000B83C5000 X22 0x0000000000000000 X23 0xAA1303E4F940E022 > X24 0x0000000000000000 X25 0x0000000000000000 X26 0x0000000000000000 X27 0x0000000000000000 > X28 0x0000000000000000 FP 0x00000000BF174A10 LR 0x00000000B83BF040 > > V0 0x0000000000000000 0000000000000000 V1 0x0000000000000000 0000000000000000 > V2 0x0000000000000000 0000000000000000 V3 0x0000000000000000 0000000000000000 > V4 0x0000000000000000 0000000000000000 V5 0x0000000000000000 0000000000000000 > V6 0x0000000000000000 0000000000000000 V7 0x0000000000000000 0000000000000000 > V8 0x0000000000000000 0000000000000000 V9 0x0000000000000000 0000000000000000 > V10 0x0000000000000000 0000000000000000 V11 0x0000000000000000 0000000000000000 > V12 0x0000000000000000 0000000000000000 V13 0x0000000000000000 0000000000000000 > V14 0x0000000000000000 0000000000000000 V15 0x0000000000000000 0000000000000000 > V16 0x0000000000000000 0000000000000000 V17 0x0000000000000000 0000000000000000 > V18 0x0000000000000000 0000000000000000 V19 0x0000000000000000 0000000000000000 > V20 0x0000000000000000 0000000000000000 V21 0x0000000000000000 0000000000000000 > V22 0x0000000000000000 0000000000000000 V23 0x0000000000000000 0000000000000000 > V24 0x0000000000000000 0000000000000000 V25 0x0000000000000000 0000000000000000 > V26 0x0000000000000000 0000000000000000 V27 0x0000000000000000 0000000000000000 > V28 0x0000000000000000 0000000000000000 V29 0x0000000000000000 0000000000000000 > V30 0x0000000000000000 0000000000000000 V31 0x0000000000000000 0000000000000000 > > SP 0x00000000BF174A10 ELR 0x00000000B83BE498 SPSR 0x60000305 FPSR 0x00000000 > ESR 0x96000004 FAR 0x1100069417FFFFE2 > > ESR : EC 0x25 IL 0x1 ISS 0x00000004 > > Data abort: Translation fault, zeroth level > ASSERT [ArmCpuDxe] /builddir/build/BUILD/ovmf-90bb4c5/ArmPkg/Library/DefaultExceptionHandlerLib/AArch64/DefaultExceptionHandler.c(184): ((BOOLEAN)(0==1)) See those "FSOpen" lines? Those are printed by the FAT driver, when it was not built with a silent log mask. So, from the above, we can tell that "shim.efi" recovers from the "Failed to set MokListRT" error, launches grub, and "grubaa64.efi" blows up. Interestingly, if I reboot the guest, interrupt the boot process, go to the UEFI shell, then launch grubaa64.efi manually, then it works all fine. If I launch "shim.efi" from the UEFI shell, then the same issue occurs. Now, let's compare the shim and grub versions, across the upgrade. The shim version doesn't change, it is "shim-0.8-8.aarch64" on both sides of the upgrade. The grub2 and grubby packages change from: grub2-efi-2.02-0.25.fc23.aarch64 grub2-tools-2.02-0.25.fc23.aarch64 grubby-8.40-2.fc23.aarch64 to: grub2-efi-2.02-0.30.fc24.aarch64 grub2-tools-2.02-0.30.fc24.aarch64 grubby-8.40-3.fc24.aarch64 The grubby change is irrelevant, it is only > * Wed Feb 03 2016 Fedora Release Engineering <releng> - 8.40-3 > - Rebuilt for https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild grub2 is more interesting: > * Thu Apr 07 2016 pjones <pjones> - 1:2.02-0.30 > - Revert 27e66193, which was replaced by upstream's 49426e9fd > Resolves: rhbz#1251600 > > * Thu Apr 07 2016 Peter Jones <pjones> - 2.02-0.29 > - Fix ppc64 build failure on fedora-24 > > * Tue Apr 05 2016 pjones <pjones> - 1:2.02-0.27 > - Pull TPM updates from mjg59. > Resolves: rhbz#1318067 > > * Tue Mar 08 2016 pjones <pjones> - 1:2.02-0.27 > - Fix aarch64 build problem. > > * Fri Mar 04 2016 Peter Jones <pjones> - 2.02-0.26 > - Rebased to newer upstream (grub-2.02-beta3) for fedora-24 I downgraded to grub2-2.02-0.27.fc24, from Koji (the smallest release increment available in Koji after 2.02-0.25). The bug persists. Then I downgraded to grub2-2.02-0.24.fc24 (again from Koji) -- the closest earlier version. With it the guest boots all fine, using shim.efi, without any manual intervention. I think the culprit is probably the rebase to upstream beta3, in the 2.02-0.26 downstream version (which was first built for aarch64 as 2.02-0.27). Namely, the changelog mentions bug 1318067, so I briefly looked that over, before the above "bisection". One of the comments there, bug 1318067 comment 33, says "It's 2 years between beta2 and beta3, per upstream's summary, with hundreds of insertions/deletions". That's where I expect the regression to come from. Reassigning to grub2, per the above results: - grub2-efi-2.02-0.24.fc24.aarch64: PASS - grub2-efi-2.02-0.25.fc23.aarch64: PASS - grub2-efi-2.02-0.27.fc24.aarch64: FAIL - grub2-efi-2.02-0.30.fc24.aarch64: FAIL Actually, this is a bug in shim. Grub is not at fault; the grub2 versions I identified above as problematic only trigger the bug in shim. (This is also evident, in retrospect, from the fact that the UEFI shell has zero problems launching grub2 directly.) Using most recent upstream shim (e22a7b5b772d), things work. I tried to bisect upstream shim, between 0.8 and e22a7b5b772d. The bisection narrowed it down to the following commit range: broken 4316fbd2a2ba Bump version to 0.8 skip 361716dd4a61 Add nostdinc to the CFLAGS for lib skip d01421eb5ae6 Align the sections we're loading, and check for validity /after/ discarding. skip 5195d7d31bde Don't install our protocols if we're not in secure mode. skip 90c65f72f882 fallback: Fix comparison between signed and unsigned in debugging code. skip 6b2510522f92 Fix length of allocated buffer for boot option comparison. skip 7fdbd9d48a4e Make lib/ build right with the cflags it should be using... fixed 605be9f1793e Make lib/ use the right CFLAGS. Those skipped commits are marked as such because they don't build. (In general my impression of the shim upstream repository is: throw patches at the wall until something sticks. There seems to be minimal effort to ensure a healthy build on *all* supported architectures. My impression is that noone cares about bisectability as a first class goal. And this shows; see above. Even just to get this far in the bisection, I regularly had to hack the Makefile (remember: I started to bisect the range 0.8..e22a7b5b772d). For example, for commits beyond 929b5b762be0 Make the build failed with objcopy < 2.24 I had to undo the changes added by this patch, because it broke the build on my aarch64 host *unconditionally*, despite my objcopy being >= 2.24! (The exact version was "2.25.1-9.el7".)) So anyway, after eyeballing the listed commits, d01421eb5ae6 looks like a clear suspect. I tried to port this commit to Fedora 24's shim-signed package, on top of build 0.8-8 (more precisely, on top of dist-git commit 99c75437001f). I have fedpkg installed on my RHEL-7 system, and I have scratch-built Fedora packages before. (I have a valid FAS account and a fresh certificate too.) Clearly, I couldn't do that in this case, because aarch64 is a secondary architecture for Fedora, with a separate Koji instance at <http://arm.koji.fedoraproject.org/koji/>; and my fedpkg doesn't know anything about it. In an aarch64 Fedora 24 guest, I installed the "fedora-packager" package. I grabbed the ARM koji configuration from it, and tried to pass it to fedpkg with --config. Unfortunately, the fedpkg command needs a *higher level* configuration file, which in turn references the koji config file. I found this higher level fedpkg config file on my RHEL-7 system (/etc/rpkg/fedpkg.conf), but I failed to customize it (beyond the reference to the ARM koji config file) for aarch64. I found no usable documentation either. Thus, shim in Fedora 24 needs a backport of upstream commit d01421eb5ae6, otherwise it corrupts the grubaa64.efi image, and I couldn't test such a build myself, because the infrastructure is plain unusable for someone who doesn't work with it every day. Not good, Fedora, not good. Yesterday I also looked at that with help from Peter Jones. Shim is definitely the source of problem. shim-signed-0.8-9 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-0b7e5ceb72 Fedora 24 cloud image from 20160518 booted perfectly: FSOpen: Open '\EFI\BOOT\BOOTAA64.EFI' Success FSOpen: Open '\EFI\BOOT\BOOTAA64.EFI' Success InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B9F3D8C0 Loading driver at 0x000B8564000 EntryPoint=0x000B8564148 Loading driver at 0x000B8564000 EntryPoint=0x000B8564148 InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BB1D3998 Failed to set MokListRT: Invalid Parameter FSOpen: Open '\EFI\BOOT\fallback.efi' Success FSOpen: Open '\EFI\BOOT\fallback.efi' Success System BootOrder not found. Initializing defaults. FSOpen: Open 'EFI' Success FSOpen: Open 'fedora' Success FSOpen: Open 'BOOT.CSV' Success FSOpen: Open '\EFI\fedora\BOOT.CSV' Success Creating boot entry "Boot0003" with label "Fedora" for file "\EFI\fedora\shim.efi" FSOpen: Open '\EFI\fedora\shim.efi' Success InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B B9F41AC0 Loading driver at 0x000B8498000 EntryPoint=0x000B8498148 Loading driver at 0x000B8498000 EntryPoint=0x000B8498148 InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF B9F3DB58 Failed to set MokListRT: Invalid Parameter FSOpen: Open '\EFI\fedora\grubaa64.efi' Success Fedora (4.5.4-300.fc24.aarch64) 24 (Cloud Edition) Use the ^ and v keys to change the selection. Press 'e' to edit the selected item, or 'c' for a command prompt. The selected entry will be started automatically in 0s. Fixed in today's compose https://dl.fedoraproject.org/pub/fedora-secondary/development/24/ shim-signed-0.8-9 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-0b7e5ceb72 shim-signed-0.8-9 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report. |