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

[Matthew Garrett <mjg59@coreos.com>]

On Wed, Aug 3, 2016 at 9:46 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Aug 3, 2016 3:43 AM, "David Howells" <dhowells@redhat.com> wrote:
>>  (1) We have to keep the module signing by keys stuff in the kernel along with
>>      a supply of keys for it to use *anyway*.  Yes, we might then be able to
>>      drop the build-time transient key, but that doesn't account for very much
>>      image space or memory.
>
> I object to the existence of the build-time key.  It completely breaks
> reproducible builds.

Keys could be stored in a separate section and ignored for the
purposes of build comparison.

>>  (3) If someone adds or updates a firmware blob, you can't simply add a new
>>      hash to the table without rebuilding your kernel.  So you need to fall
>>      back to using a key-based signature for this.
>>
>
> As above, firmware isn't affected.

There's no fundamental problem with using signed firmware (although
you'd probably need detached signatures to comply with licenses) -
it's more of a logistical problem in that you'd need an actual key
rather than a build-time one, but it's still more practical than
hashing.

>> I don't see a compelling argument for why we'd want to do module hashing at
>> all, given that we have to have the signature checking mechanism around anyway
>> for various reasons.
>
> I think that, for the Secure Boot usecase, we actually wouldn't need
> the signature checking mechanism at all.  Firmware signature checking
> in-kernel is important for some chain-of-trust use cases but AFAIK not
> for Secure Boot for standard desktop distros.

Without an IOMMU you can probably subvert any DMA capable device that
loads unsigned firmware, at which point you're in a bad place again.
This isn't something I'm losing much sleep over, since attacks that
only work if you have a specific piece of hardware installed are much
less exciting. We'd still need signature checking so that users can
install their own signing keys, and I don't see distributions being
terribly enthusiastic about having two unrelated module validation
systems.