linux-kernel - Re: [RFC v1 05/12] firmware: add firmware signature checking support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 06 May 2015 17:57:59 +0100
From:	David Howells <dhowells@...hat.com>
To:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>
Cc:	dhowells@...hat.com, rusty@...tcorp.com.au, ming.lei@...onical.com,
	seth.forshee@...onical.com, kyle@...nel.org,
	akpm@...ux-foundation.org, gregkh@...uxfoundation.org,
	keescook@...omium.org, casey@...aufler-ca.com, tiwai@...e.de,
	mjg59@...f.ucam.org, wireless-regdb@...ts.infradead.org,
	linux-wireless@...r.kernel.org, jlee@...e.com,
	linux-kernel@...r.kernel.org, "Luis R. Rodriguez" <mcgrof@...e.com>
Subject: Re: [RFC v1 05/12] firmware: add firmware signature checking support

Luis R. Rodriguez <mcgrof@...not-panic.com> wrote:

> As with module signing, we do a very simple search for a
> particular string appended to the firmware. There's both a
> config option and a boot parameter which control whether we
> accept or fail with unsigned firmware and firmware that are
> signed with an unknown key.
> 
> If firmware signing is enabled, the kernel will be tainted
> if a firmware is loaded that is unsigned or has a signature
> for which we don't have the key.

I think you need to be careful storing the firmware blobs on disk with
signatures attached for two reasons:

 (1) There may be licensing/copyright issues on these blobs if you alter them.

 (2) Someone might try loading the modified blob without the signature being
     stripped - say someone runs an old kernel or copies the blob to a
     non-Linux system and tries to load it there.

Adding the signature to the blob upon loading might be less problematic, but
it still potentially suffers from (2) above.

If you switch to PKCS#7, you can also embed the blob inside the PKCS#7
message, so essentially the blob is unmodified and can be verified or
extracted by any suitable PKCS#7 tool.  This is more likely to get the
firmware rejected if the kernel isn't expecting it to be signed, I think.

I'm not sure how userspace actually passes the firmware blob to the kernel,
but I do think that if you can, you should pass the signature separately to
the blob.

With kernel modules this doesn't matter since modules are typically tied to a
single kernel version anyway.

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/