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]

Message-ID: <s5hip9k9dng.wl%tiwai@suse.de>
Date:	Mon, 05 Nov 2012 18:13:07 +0100
From:	Takashi Iwai <tiwai@...e.de>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	joeyli <jlee@...e.com>, 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

At Thu, 1 Nov 2012 13:18:49 +0000,
Alan Cox wrote:
> 
> > 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.
> 
> Then you'd better stop storing it on disk because your disk drive is FEC
> encoding it and adding a CRC 8)
> 
> It does want checking with a lawyer but my understanding is that if you
> have a file which is a package that contains the firmware and a signature
> then there is not generally a problem, any more than putting it in an RPM
> file - it's packaging/aggregation. This should be referred to the Linux
> Foundation folks perhaps - no point designing something badly to work
> around a non existant issue.
> 
> Also the interface needs to consider that a lot of device firmware is
> already signed. Nobody notices because they don't ever try and do their
> own thus many drivers don't need extra signatures in fact.

Besides the legal concern, embedding the signature into the firmware
makes the file incompatible with old kernel that has no support for
signed firmware.  That's the reason I put the files into a new
location in my test patch, /lib/firmware/signed/.  Having a separate
signature file would make this easier.

I cooked again quickly firmware loader code for the separate signature
files.  I'm going to send a series of test patches.


thanks,

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