Firmware signing -- Re: [PATCH 00/27] security, efi: Add kernel lockdown
Luis R. Rodriguez
mcgrof at kernel.org
Tue Nov 14 20:50:14 UTC 2017
On Tue, Nov 14, 2017 at 12:18:54PM -0800, Linus Torvalds wrote:
> This is all theoretical security masturbation. The _real_ attacks have
> been elsewhere.
In my research on this front I'll have to agree with this, in terms of
justification and there are only *two* arguments which I've so far have found
to justify firmware signing:
a) If you want signed modules, you therefore should want signed firmware.
This however seems to be solved by using trusted boot thing, given it
seems trusted boot requires having firmware be signed as well. (Docs
would be useful to get about where in the specs this is mandated,
anyone?). Are there platforms that don't have trusted boot or for which
they don't enforce hardware checking for signed firmware for which
we still want to support firmware signing for? Are there platforms
that require and use module signing but don't and won't have a trusted
boot of some sort? Do we care?
b) Other kernel components have implemented some sort of "signing" a file
prior to sending it to the kernel. One is wifi for the regulatory.bin,
through CRDA, and this helped us persuade certain folks to support wifi
with open drivers. We can easily replace CRDA with kernel fetch for a
signed file given most of the APIs for this is available.
Originally effort a) was done for b), as it was believed we needed a).
If we are saying a) is pointless, what about b)? A simple new
kernel_read_file_from_path_pkcs7_signed() or some such would suffice.
Johannes made cfg80211 recently just use request_firmware() now via commit on
linux-next 90a53e4432 ("cfg80211: implement regdb signature checking") [0] as
he got tired of waiting firmware signing, but note he implemented a signature
checking on its own so he open codes verify_pkcs7_signature() after the
request_firmware() call. If we are happy to live with this, then so be it.
[0] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=90a53e4432b12288316efaa5f308adafb8d304b0
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the Linux-security-module-archive
mailing list