linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).