linux-kernel - Re: [RFC] Second attempt at kernel secure boot 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:	Thu, 01 Nov 2012 12:21:55 +0800
From:	joeyli <jlee@...e.com>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	Jiri Kosina <jkosina@...e.cz>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org, linux-efi@...r.kernel.org
Subject: Re: [RFC] Second attempt at kernel secure boot support

於 三，2012-10-31 於 19:53 +0100，Takashi Iwai 提到：
> At Wed, 31 Oct 2012 17:37:28 +0000,
> Matthew Garrett wrote:
> > 
> > On Wed, Oct 31, 2012 at 06:28:16PM +0100, Takashi Iwai wrote:
> > 
> > > request_firmware() is used for microcode loading, too, so it's fairly
> > > a core part to cover, I'm afraid.
> > > 
> > > I played a bit about this yesterday.  The patch below is a proof of
> > > concept to (ab)use the module signing mechanism for firmware loading
> > > too.  Sign firmware files via scripts/sign-file, and put to
> > > /lib/firmware/signed directory.
> > 
> > That does still leave me a little uneasy as far as the microcode 
> > licenses go. I don't know that we can distribute signed copies of some 
> > of them, and we obviously can't sign at the user end.
> 
> Yeah, that's a concern.  Although this is a sort of "container" and
> keeping the original data as is, it might be regarded as a
> modification.
> 
> Another approach would be to a signature in a separate file, but I'm
> not sure whether it makes sense.
> 

I think it make sense because the private key is still protected by
signer. Any hacker who modified firmware is still need use private key
to generate signature, but hacker's private key is impossible to match
with the public key that kernel used to verify firmware.

And, I afraid we have no choice that we need put the firmware signature
in a separate file. Contacting with those company's legal department
will be very time-consuming, and I am not sure all company will agree we
put the signature with firmware then distribute.


Thanks a lot!
Joey Lee

--
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/