Bug#966554: grub2-common: BootHole fixes in DSA-4735-1 break dual-boot with Windows

Janek Stolarek jwstolarek at gmail.com
Fri Aug 14 12:06:32 BST 2020


Hi guys,

I believe the fix for this bug introduced a security regression that I only noticed just now. 
Recall how I was able to test whether Secure Boot is enabled:

[root at skynet : ~] dmesg | grep secu
[    0.000000] secureboot: Secure boot enabled

Here's what I get now:

[root at skynet : ~]  dmesg | grep secu
[    0.000000] secureboot: Secure boot could not be determined (mode 0)

This happens both on kernel 5.6 (used when I reported the bug originally) and 5.7. I wanted to 
double-check that this is due to the fix in grub but the old packages are no longer in the repo 
so I can't downgrade to test. Googling points me to similar past bug in GRUB:

https://bugzilla.redhat.com/show_bug.cgi?id=1418360

and the suggestion there is that "failure detect secure boot status causes the kernel to disable a 
number of security checks" which makes this a security issue. There'a also a lot of technical 
discussion that I don't follow but it probably will make more sense to you.

Should I file a separate bug report for this?

Janek



More information about the Pkg-grub-devel mailing list