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 1465517 - Secure boot value is clobbered due to bug in grub; reinstate pre-sanitisation of boot_params
Summary: Secure boot value is clobbered due to bug in grub; reinstate pre-sanitisation...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 25
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1451071
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-06-27 14:40 UTC by David Howells
Modified: 2017-12-12 10:31 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1451071
Environment:
Last Closed: 2017-12-12 10:31:07 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

Description David Howells 2017-06-27 14:40:05 UTC 
+++ This bug was initially created as a clone of Bug #1451071 +++

Secure boot is activated in the bios and i can boot without issue.

But dmesg output is :
dmesg -t | grep -i 'edk\|secure'
Secure boot could not be determined

While normally it should be:
Secure boot enabled and kernel locked down

Kernel 4.11.0-2.fc26.x86_64
Bootloader : Grub2

--- Additional comment from David Howells on 2017-05-16 08:55:21 EDT ---

What grub version do you have?  There's a bug in grub that might be the culprit (bug 1418360).

--- Additional comment from  on 2017-05-16 09:55:28 EDT ---

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

--- Additional comment from  on 2017-05-18 05:56:09 EDT ---

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

--- Additional comment from  on 2017-05-19 03:44:27 EDT ---

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

--- Additional comment from David Howells on 2017-05-24 08:51:17 EDT ---

The bug has not yet been fixed in grub.

--- Additional comment from hanishkvc on 2017-06-05 09:19:06 EDT ---

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?

--- Additional comment from  on 2017-06-21 04:55:23 EDT ---

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...

--- Additional comment from Fedora Update System on 2017-06-26 17:27:56 EDT ---

grub2-2.02-0.40.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-01b07bc086

--- Additional comment from Fedora Blocker Bugs Application on 2017-06-26 17:33:27 EDT ---

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.

--- Additional comment from Dominik 'Rathann' Mierzejewski on 2017-06-27 06:15:23 EDT ---

(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.
Comment 1 David Howells 2017-06-27 14:47:31 UTC 
This occurs in F25 also because the sanitize_boot_params() call that used to be made before the secure boot state was evaluated wasn't allowed in upstream (it *should* be unnecessary - except that it gets tripped by bug 1418360).

For F25 it's probably best to put back the sanitize_boot_params() call that was removed.
Comment 2 dherault 2017-06-28 07:43:59 UTC 
Version 0.38 allowed unsigned modules to pass. I was able to boot with unsigned nvidia drivers. I discovered this by asking myself why the 0.40 did not boot ...
Comment 3 Dave Young 2017-07-18 07:03:01 UTC 
*** Bug 1470995 has been marked as a duplicate of this bug. ***
Comment 4 Fedora End Of Life 2017-11-16 19:28:25 UTC 
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 5 Fedora End Of Life 2017-12-12 10:31:07 UTC 
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Note You need to log in before you can comment on or make changes to this bug.