No. It's only present in F18 and rawhide, but it's still there.
OK, thanks.
I'm guessing you meant "Secure Boot" and not "UEFI".
Yeah, sorry, that's what I meant.
If so, the answer
is sort of. grub2 won't check the kernel, but it will still be signed
if it's a 64-bit F18 or newer release kernel.
Would that be possible - for the kernel to be checked - or is that only
allowed from Secure Boot?
The modules will all be
signed regardless as that's done with a different key generated at
kernel build time.
The whole point of me asking this is, because I wish to use my own key
(not Fedora's and certainly not M$) and when I build the kernel - from
source - I wish this to be signed and later enforced, if possible.
There's a kernel parameter you can enable to force
the kernel into a "secure boot" mode.
I presume I could find the appropriate parameter documented in the
kernel docs directory, right?
Without the secure firmware, I'm not entirely sure why you'd want to do
that though. It won't prevent bootloader based attacks.
I am aware of that, but at least it would prevent loading rogue modules,
which either haven't been signed or have been altered.
If you just
want signed modules, there's a different kernel parameter you can pass
to enforce signed modules.
Ideally, I'd like to protect the kernel as well, but if that's not
possible then just the modules will do.
In an ideal world, I would like to have the option to boot my UEFI in
"Setup" mode so that I could register my own platform key, which could
then be used to register all other "trusted" keys (including the M$ one
- if I choose to trust it) and then enable UEFI to boot in as normal,
enforcing bootloader, kernel as well as kernel module signatures.
In reality though, I am finding it difficult to find a hardware
manufacturer who distributes motherboards with that option enabled (UEFI
in "Setup" mode) - the most I could get, and it still seems a rarity
these days, is to have a separate key registered, alongside the already
existing one (which, in 99% of the cases is from M$).
That, while acceptable somewhat, forces me to trust the master key,
which I am not willing to do - it should be up to me as owner of my own
hardware (My PC!) to choose what to trust and what not to. Apologies for
this rant, but it had to be said!
_______________________________________________
kernel mailing list
kernel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/kernel
