From: David Howells <dhowells@redhat.com>
To: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Cc: dhowells@redhat.com, ming.lei@canonical.com,
rusty@rustcorp.com.au, torvalds@linux-foundation.org,
seth.forshee@canonical.com, linux-kernel@vger.kernel.org,
pebolle@tiscali.nl, linux-wireless@vger.kernel.org,
gregkh@linuxfoundation.org, jlee@suse.com, tiwai@suse.de,
casey@schaufler-ca.com, keescook@chromium.org,
mjg59@srcf.ucam.org, akpm@linux-foundation.org,
"Luis R. Rodriguez" <mcgrof@suse.com>,
Kyle McMartin <kyle@kernel.org>,
David Woodhouse <David.Woodhouse@intel.com>
Subject: Re: [RFC v3 2/2] firmware: add firmware signature checking support
Date: Tue, 19 May 2015 11:02:44 +0100 [thread overview]
Message-ID: <9412.1432029764@warthog.procyon.org.uk> (raw)
In-Reply-To: <1431996325-8840-3-git-send-email-mcgrof@do-not-panic.com>
Luis R. Rodriguez <mcgrof@do-not-panic.com> wrote:
> +The kernel firmware signing facility enables to cryptographically sign
> +firmware files on a system using the same keys used for module signing.
> +Firmware files's signatures consist of PKCS#7 messages of the respective
> +firmware file. A firmware file named foo.bin, would have its respective
> +signature on the filesystem as foo.bin.p7s. When firmware signature
> +checking is enabled (FIRMWARE_SIG) and when one of the above APIs is used
> +against foo.bin, the file foo.bin.p7s will also be looked for. If
> +FIRMWARE_SIG_FORCE is enabled the foo.bin file will only be allowed to
> +be returned to callers of the above APIs if and only if the foo.bin.p7s
> +file is confirmed to be a valid signature of the foo.bin file. If
> +FIRMWARE_SIG_FORCE is not enabled and only FIRMWARE_SIG is enabled the
> +kernel will be permissive and enabled unsigned firmware files, or firmware
> +files with incorrect signatures. If FIRMWARE_SIG is not enabled the
> +signature file is ignored completely.
I'd rework this paragraph somewhat. How about:
The kernel firmware signing facility enables firmware files on a system to
have associated cryptographic signatures that can be used to validate them.
This uses the same mechanism as is used for module signing.
Firmware signatures are kept in separate files from the actual firmware data
to avoid accidental corruption of the firmware and to avoid licensing issues
from changes.
A firmware signature file consists of a PKCS#7 message containing one or
more cryptographic signatures for the respective firmware file. The
signature file is named for the firmware file to which it corresponds and
must be kept in the same directory. For instance, for the signature file
for a firmware file named foo.bin would be named foo.bin.p7s.
When firmware signature checking is enabled (CONFIG_FIRMWARE_SIG) and when
one of the above APIs is used against foo.bin, the file foo.bin.p7s will
also be looked for.
If a signature file is found, the kernel's system keyring will be searched
for public keys that can be used to verify the signatures held therein. For
any signature for which a matching key is found, the kernel will attempt to
verify the signature with the key. If verification fails on any signature,
the firmware load will be rejected (with EKEYREJECTED) - even if other
signatures match.
If CONFIG_FIRMWARE_SIG_FORCE is also enabled, then the firmware load will be
rejected (with ENOKEY) if there is no signature file or none of the
signatures match any of the keys in the kernel system keyring. But if at
least one signature matches, then the load will be allowed to proceed.
If CONFIG_FIRMWARE_SIG is not enabled the signature file is ignored
completely.
David
next prev parent reply other threads:[~2015-05-19 10:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-19 0:45 [RFC v3 0/2] firmware: add PKCS#7 firmware signature support Luis R. Rodriguez
2015-05-19 0:45 ` [RFC v3 1/2] firmware: generalize reading file contents as a helper Luis R. Rodriguez
2015-05-19 0:45 ` [RFC v3 2/2] firmware: add firmware signature checking support Luis R. Rodriguez
2015-06-08 19:56 ` Kees Cook
2015-07-14 19:20 ` Luis R. Rodriguez
2015-07-21 23:14 ` Luis R. Rodriguez
2015-05-19 9:33 ` David Howells
2015-05-19 16:23 ` Luis R. Rodriguez
2015-05-19 10:02 ` David Howells [this message]
2015-05-19 16:31 ` Luis R. Rodriguez
2015-05-22 15:21 ` [RFC v3 0/2] firmware: add PKCS#7 firmware signature support David Howells
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9412.1432029764@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=David.Woodhouse@intel.com \
--cc=akpm@linux-foundation.org \
--cc=casey@schaufler-ca.com \
--cc=gregkh@linuxfoundation.org \
--cc=jlee@suse.com \
--cc=keescook@chromium.org \
--cc=kyle@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mcgrof@do-not-panic.com \
--cc=mcgrof@suse.com \
--cc=ming.lei@canonical.com \
--cc=mjg59@srcf.ucam.org \
--cc=pebolle@tiscali.nl \
--cc=rusty@rustcorp.com.au \
--cc=seth.forshee@canonical.com \
--cc=tiwai@suse.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).