Re: [Ksummit-discuss] [TOPIC] Secure/verified boot and roots of trust

[Mimi Zohar <zohar@linux.vnet.ibm.com>]

On Wed, 2016-08-17 at 12:38 +0100, Ben Hutchings wrote:
> On Thu, 2016-08-04 at 00:01 +0100, Ben Hutchings wrote:
> > On Wed, 2016-08-03 at 09:46 -0700, Andy Lutomirski wrote:
> > [...]
> > > 
> > > And it gets rid of the IMO extremely nasty temporary key.  I
> > > personally think that reproducible builds would add considerable
> > > value
> > > to many use cases, and we currently can't simultaneously support
> > > reproducible builds and Secure Boot without a big mess involving
> > > trusted parties, and the whole point of reproducible builds is to
> > > avoid needed to trust the packager.
> > [...]
> > 
> > You need that trusted party to supply a signature for the kernel, so
> > why is it so much worse to have them do that for the modules as well?
> [...]
> 
> I think I can now answer this myself.
> 
> Where there's a separate certificate store, the signing stage can be
> entirely independent of the initial build.  A user of a distribution
> can reproduce the distribution's unsigned binaries and then use their
> own keys to build signed binaries for their own use.
> 
> However, the module signing certificate embedded in the kernel - even
> if it refers to a persistent signing key, making it reproducible - has
> to be established before the initial build, so it doesn't allow for
> users to use a different root of trust.  So there ought to be an option
> to require signatures but without defining any trusted keys at build
> time.

With Mehmet Kayaalp's patches memory can be reserved for adding keys
post build.  After adding the key, the kernel would need to be
(re-)signed.

c4c3610 "KEYS: Reserve an extra certificate symbol for inserting without
recompiling"
8e16789 "KEYS: Use the symbol value for list size, updated by
scripts/insert-sys-cert"

Mimi