On Sat, Oct 27, 2012 at 10:04 PM, Joshua C. <joshuacov@xxxxxxxxx> wrote:
>> AIUI, those lockdowns are supposed to only apply if Restricted ("Secure")
>> Boot is supported by and enabled in the BIOS (or rather, the UEFI
>> firmware;
>> traditional BIOSes don't have that misfeature).
Correct.
> I see but is there a general switch do disable those even if secure boot is
> set to enable in the uefi firmware?
No. There is not.
> Honestly looking into the latest patch applied to the rawhide-kernel, I
> cannot see any indication that those lockups occur only if secure boot is
> set in the uefi firmware. They just lock out the user space regardless of
> what the uefi says...
That is utterly incorrect. First, you really mean lockdowns, not
lockups (they mean different things to kernel people). Secondly, which
lockdowns are you concerned with?
Most of the changes to disallow various things are guarded by checking
for CAP_COMPROMISE_KERNEL. That is only dropped if the machine has UEFI
and if Secure Boot is enabled. That is checked very early in the boot
process in arch/x86/kernel/setup.c.
The other side is signed modules. That is enabled regardless, however
it is not put into enforcing mode until your machine has Secure Boot
enabled. So while all of the Fedora kernel modules are signed, you can
still load unsigned modules, or modules that are signed by third parties
without issue. The most recent change in this area will import certs
from UEFI to actually _help_ people use modules signed with a different
cert while still remaining compliant with the Secure Boot architecture.
But again, that doesn't even happen unless Secure Boot is enabled in the
firmware on that machine.
So, this patchset really shouldn't impact you at all unless you have a
machine booting with UEFI with Secure Boot enabled. If you do, and you
want a switch to just turn it off and not mess with it, then turn it
off in UEFI.
josh
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
