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

[Matthew Garrett <mjg59@coreos.com>]

On Tue, Aug 2, 2016 at 9:34 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Tue, Aug 2, 2016 at 8:32 PM, Matthew Garrett <mjg59@coreos.com> wrote:
>> 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?

A physically present user can just disable Secure Boot. Shim has
support for doing this, at which point enforcement is disabled for the
rest of the boot chain.

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

Yeah, I think in general this would be incredibly useful. There's
various things that I've ended up implementing in x86 specific ways
because there's no standard way to pass significant quantities of data
between the boot environment and the kernel proper. DeviceTree is
probably the closest we have, but it's still somewhat architecture
specific and then we're suddenly having to deal with DTB+ACPI
scenarios we haven't necessarily planned for.