boot: Follow-up fixes for #20255 #24189
Conversation
bluca
added
the
good-to-merge/waiting-for-ci 👍
man/loader.conf.xml
Outdated
| sign-efi-sig-list -c KEK.crt -k KEK.key db db.tmp db.esl | ||
| # This step adds the Microsoft Windows and UEFI keys to the database and is optional, but recommended. | ||
| # The first key is needed to be able to use the Windows boot loader, the second key is needed for | ||
| # firmware drivers and third-party boot loaders signed by Microsoft. |
There was a problem hiding this comment.
drivers of the platform firmware don't have to be signed btw, they are trusted because loaded from a trusted storage source.
I think we should mention the expression "option ROM" here, because that's what it really is about, i.e. stuff that is neither from the platform vendor nor from the OS vendor, but on some extension card.
There was a problem hiding this comment.
Agree, with @poettering here.
Should we maybe add an '(e.g. shim)' after third-party bootloader here? This would probably be the most common case.
There was a problem hiding this comment.
By the way, I think there has been multiple vulnerabilities discovered in signed version of the shim. Doesn't loading the microsoft key without loading any dbx for blacklisting these versions open you up to anyone booting the vulnerable shim and using it to do anything?
Maybe I'm thinking too far here.
There was a problem hiding this comment.
@poettering I would not trust a vendor to always have their internal drivers be trusted. I did add option ROM (it's really a terrible name, considering they are less than optional for nvidia GPUs, even on laptops).
@vdagonneau-anssi That's a good point. The nice thing is that we have nothing to do here: :D
Microsoft provides a third key (KEK) which is used to sign the official dbx updates. So I just added that key to the instructioins and referred to fwupdmgr to update the dbx.
man/loader.conf.xml
Outdated
| sign-efi-sig-list -c PK.crt -k PK.key PK PK.tmp PK.esl | ||
| sign-efi-sig-list -c PK.crt -k PK.key KEK KEK.tmp KEK.esl | ||
| sign-efi-sig-list -c KEK.crt -k KEK.key db db.tmp db.esl | ||
| # This step adds the Microsoft Windows and UEFI keys to the database and is optional, but recommended. |
There was a problem hiding this comment.
I'd say "Microsoft Windows and Microsoft 3rd Party certificates"
There was a problem hiding this comment.
I'd also conditionalize the "but recommended" a bit. i.e. say it's recommended for general purpose OSes.
After all, in environments such as VMs the Microsoft keys are pretty irrelevant, and even a bad idea. Hence, if you focus on VMs only, or on a specific platform, don't bother with the Microsoft keys. In fact, it might be wise to turn this around altogether, and mention outside of bare metal systems where dual boot with another OS or where option ROM devices are used it's totally unnecessary.
poettering
added
good-to-merge/with-minor-suggestions
and removed
good-to-merge/waiting-for-ci 👍
|
looks good, some minor comments. @vdagonneau-anssi could you have a look, too? |
Adding Microsoft keys by default is recommended because firmware drivers might be signed by it. This also changes the file ending from .esl to .auth as that is used by sign-efi-sig-list manpage and other sources.
|
I also added a another commit to skip the safety countdown in VMs. |
poettering
added
good-to-merge/waiting-for-ci 👍
|
lgtm |
4 participants
No description provided.