[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9412.1432029764@warthog.procyon.org.uk>
Date: Tue, 19 May 2015 11:02:44 +0100
From: David Howells <dhowells@...hat.com>
To: "Luis R. Rodriguez" <mcgrof@...not-panic.com>
Cc: dhowells@...hat.com, ming.lei@...onical.com, rusty@...tcorp.com.au,
torvalds@...ux-foundation.org, seth.forshee@...onical.com,
linux-kernel@...r.kernel.org, pebolle@...cali.nl,
linux-wireless@...r.kernel.org, gregkh@...uxfoundation.org,
jlee@...e.com, tiwai@...e.de, casey@...aufler-ca.com,
keescook@...omium.org, mjg59@...f.ucam.org,
akpm@...ux-foundation.org, "Luis R. Rodriguez" <mcgrof@...e.com>,
Kyle McMartin <kyle@...nel.org>,
David Woodhouse <David.Woodhouse@...el.com>
Subject: Re: [RFC v3 2/2] firmware: add firmware signature checking support
Luis R. Rodriguez <mcgrof@...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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists