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 1451071
Summary: | Secure boot flag could not be determined | |||
---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | dherault | |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 26 | CC: | awilliam, bugzilla, dhowells, dominik, gansalmon, hanishkvc, ichavero, itamar, jonathan, kernel-maint, madhu.chinakonda, mchehab, mjg59, pjones, robatino, thomas | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | x86_64 | |||
OS: | Linux | |||
Whiteboard: | AcceptedFreezeException | |||
Fixed In Version: | grub-2.02-0.40.fc26 | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1465517 (view as bug list) | Environment: | ||
Last Closed: | 2017-06-29 23:28:34 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: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1349188, 1349189, 1465517 |
Description
dherault
2017-05-15 17:08:08 UTC
What grub version do you have? There's a bug in grub that might be the culprit (bug 1418360). The last one : 1:2.02-0.38.fc26 I have at boot a EFI stub message that informs me that secure boot is enabled. But no kernel lockdown for dmesg. Maybe the problem is for me related to the fact that I activated secure boot after the installation of the system? efibootmgr -v BootCurrent: 0001 Timeout: 1 seconds BootOrder: 0001,0000,0005 Boot0000* Windows Boot Manager HD(2,GPT,e3179291-056a-448c-a5a1-ba56fb60e852,0xe1800,0x32000)/File(\EFI\MICROSOFT\BOOT\BOOTMGFW.EFI)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...7................ Boot0001* Fedora HD(1,GPT,fe1e748e-4c4a-4791-b11f-3865772b4ce3,0x800,0x2f800)/File(\EFI\FEDORA\SHIM.EFI) Boot0005* UEFI OS HD(1,GPT,fe1e748e-4c4a-4791-b11f-3865772b4ce3,0x800,0x2f800)/File(\EFI\BOOT\BOOTX64.EFI) Secureboot efivar is present, but not SecurebootEnforce... ls /sys/firmware/efi/efivars/ |grep Secure* SecureBoot-8be4df61-93ca-11d2-aa0d-00e098032b8c Thanks Kernel updated to 4.11.1-300.fc26.x86_64 : Same issue dmesg |grep Secur* [ 0.000000] Secure boot could not be determined If it can be useful : bootctl status Using EFI System Partition at /boot/efi. System: Firmware: n/a (n/a) Secure Boot: enabled Setup Mode: user Loader: Product: n/a Partition: n/a File: └─n/a Boot Loader Binaries: ESP: /dev/disk/by-partuuid/fe1e748e-4c4a-4791-b11f-3865772b4ce3 systemd-boot not installed in ESP. File: └─/EFI/BOOT/BOOTX64.EFI Boot Loader Entries in EFI Variables: Title: Fedora ID: 0x0001 Status: active, boot-order Partition: /dev/disk/by-partuuid/fe1e748e-4c4a-4791-b11f-3865772b4ce3 File: └─/EFI/FEDORA/SHIM.EFI Title: Windows Boot Manager ID: 0x0000 Status: active, boot-order Partition: /dev/disk/by-partuuid/e3179291-056a-448c-a5a1-ba56fb60e852 File: └─/EFI/MICROSOFT/BOOT/BOOTMGFW.EFI Title: UEFI OS ID: 0x0005 Status: active, boot-order Partition: /dev/disk/by-partuuid/fe1e748e-4c4a-4791-b11f-3865772b4ce3 File: └─/EFI/BOOT/BOOTX64.EFI Tried to reinstall grub-efi but same issue : sudo dnf reinstall grub2-efi grub2-efi-modules shim sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg The bug has not yet been fixed in grub. Any specific reason why this bug is still not resolved? Also isn't there a bug in kernel also. Looking at the note given in struct boot_param, as well as how the efi boot wrapper within in the kernel is using some part of the boot_param to set its own parameters, after it has got control from the original bootloader, why is the sanitize_boot_params WRONGLY reseting parameters which are (or can be as is the case here) set outside/after the bootloader. Other than fixing the blind and potentially wrong copying of parameters area into boot_param by grub. The kernel should also be fixed to have some additional parameter to check if bootloader has set the secure boot related params or the kernel's efi boot wrapper has set it, and then sanitize only if required. OR am I missing something here? Same issue kernel 4.11.5-300 FC26 beta. I do not have the impression that this bug is moving to be fixed. If the grub team is the only one competent, is their informed of this bug? Replacing grub with a signed systemd-boot could help solve the problem. But I do not know if it's in the pipes... grub2-2.02-0.40.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-01b07bc086 Proposed as a Blocker and Freeze Exception for 26-final by Fedora user pjones using the blocker tracking app because: Without this we can't verify from inside the OS that Secure Boot is enabled. (In reply to Fedora Update System from comment #8) > grub2-2.02-0.40.fc26 has been submitted as an update to Fedora 26. > https://bodhi.fedoraproject.org/updates/FEDORA-2017-01b07bc086 What about F25? The issue occurs there as well. grub2-2.02-0.40.fc26 has been pushed to the Fedora 26 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-2017-01b07bc086 Same question as the other bug: Would the fix for this take effect after a normal update of grub2, or is there some reason the fix for this needs to appear in the frozen release package set? Also, presumably *both* fixes are needed? For the record, pjones added further information by email: "basically Secure Boot doesn't trigger kmod signature checking, read-only /dev/mem, etc., in the current trees. This update fixes a grub bug that's triggering that behavior in the newer kernels, but was not triggering it in the older ones." AIUI, "kmod signature checking, read-only /dev/mem, etc." refers to various measures that are taken by the kernel when SB is known to be enabled, intended to defeat attempts to circumvent SB by e.g. loading a nefarious kernel module. So if I understand correctly, this is effectively a security issue (as it reduces the effectiveness of SB protections on systems which are using SB). With that in mind: Discussed at 2017-06-29 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2017-06-29/f26-blocker-review.2017-06-29-16.00.html . We agreed to at least accept this (and the companion bug #1418360) as freeze exception issues, which should be sufficient to ensure they're resolved in Final as the fixes are already available. We considered also accepting them as blockers under the "The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)." criterion, but as this issue isn't *formally* a security issue at least yet, and doesn't have a formal security evaluation, and FE status should be sufficient to get the fixes in anyhow, we decided to leave blocker status undetermined for now. FESCo may choose to make these bugs blockers by fiat. grub2-2.02-0.40.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. |