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

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Aug 02, 2016 at 09:34:14PM -0700, Andy Lutomirski wrote:
> On Tue, Aug 2, 2016 at 8:32 PM, Matthew Garrett <mjg59@coreos.com> wrote:
> > On Tue, Aug 2, 2016 at 7:58 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> >>  - Appeasing the Secure Boot deities.  AFAIK this specifically
> >> requires that we verify the kernel and its modules using a combination
> >> of EFI-supplied and distro keys.
> >
> > Eh not quite. The rules are basically that if a Microsoft-signed
> > object can be used to compromise other operating systems, Microsoft
> > may unilaterally blacklist that object. Allowing arbitrary module
> > loading or arbitrary kexec clearly makes it straightforward to simply
> > use a signed Linux boot chain to then boot a compromised version of
> > any other operating system, defeating the point of Secure Boot.
> 
> > Distro
> > keys are used for module signing because that's the easiest way to
> > handle it (sign them during build and then discard the key),
> 
> With my module hashing patches, that'll be even simpler.  The kernel
> image will contain a list of SHA256 hashes of in-tree .ko files and
> will accept those files.

Hmm. I kind of like ability to build and add modules to a running
kernel. And I think some distros might use it too, updating modules
without updating the kernel (doesn't work if you discard the key,
obviously).

> > UEFI keys
> > are used to appease some manufacturers (they can ship their
> > binary-only drivers signed with a key that's in firmware) and shim
> > keys are used to allow users to sign their own modules.
> 
> Hmm.  Would it be okay if a physically present user could subvert it?
> For example, if a physically present user typed "insecure" into a
> bootloader command line and thus turned off signature verification?

Typically already possible with firmware menus.

> >>  - Bootloader supplies public keys and policy to the kernel.
> >
> > The main problem here is the lack of a standardised way of passing
> > data from bootloader to kernel. We can't just append a CPIO to the
> > initramfs because using arbitrary initramfs is a reasonable policy for
> > many usecases. Having a secure architecture-independent communications
> > channel between the bootloader and the kernel would be helpful in
> > various ways.
> 
> Indeed.  I wonder if we could design such a thing?  Or at least
> something that requires only minimal arch-specific work.
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss