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