[Ksummit-discuss] [TOPIC] Secure/verified boot and roots of trust
Matthew Garrett
mjg59 at coreos.com
Wed Aug 3 17:17:49 UTC 2016
On Wed, Aug 3, 2016 at 9:46 AM, Andy Lutomirski <luto at amacapital.net> wrote:
> On Aug 3, 2016 3:43 AM, "David Howells" <dhowells at 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.
More information about the Ksummit-discuss
mailing list