On 15-05-21 10:02:36, [email protected] wrote:
> On Thu, May 21, 2015 at 04:03:02PM +0000, Woodhouse, David wrote:
> >
> > In a lot of cases we have loadable firmware precisely to allow us to
> > reduce the cost of the hardware. Adding cryptographic capability in the
> > 'load firmware' state of the device isn't really compatible with that
> > :)
>
> We do? What devices want this? That's really a bad hardware design to trust
> the kernel to get all of this correct.
Which means nearly all hardware we use today is badly designed... :)
> And I say this as someone who is currently working on a hardware design that
> does just this for a very tiny device. It's only a few hundred bytes of
> firmware size to be able to do proper key verification that the firmware
> image
> is correct and can be "trusted".
And a "few" more bytes for the hash algorithm along the one for asymmetric key
computation and management. :)
> > In the case where kernel and modules are signed, it *is* useful for a
> > kernel
> > device driver also to be able to validate that what it's about to load into
> > a device is authentic. Where 'authentic' will originally just mean that
> > it's
> > come from the linux-firmware.git repository or the same entity that built
> > (and signed) the kernel, but actually I *do* expect vendors who are
> > actively
> > maintaining the firmware images in linux-firmware.git to start providing
> > detached signatures of their own.
>
> Again, why have a detached signature and not just part of the firmware blob?
> The device needs to be caring about this, not the kernel.
In ideal world this is what should be done. However, adding the simplest (read
slowest) MD5 implementation requires a few K's of ram on 32bit cpu. MD5 is
dead. So we need SHA-something, which isn't smaller in terms of code size.
Add
the asymmetric cryptography to the picture and we've already put away all
vendors.
> As the kernel doesn't know/care about what the firmware blob really is, I
> don't see why it should be caring about firmware signing as that's a binary
> running on a separate "computer". Do we want to take this the next logical
> step further and start requiring networked devices to attest their kernels
> are
> signed correctly before we can talk to them?
I think it is enough for you to know that your iwlwifi's firmware comes from
Intel and not from a random Internet punk. If you trust Intel with your wifi
adapter you probably trust them to write good firmware for it.
Petko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
