Am Mittwoch, 16. Januar 2013, 10:09:29 schrieb Oliver
On Tuesday 15 January 2013 23:55:02 Greg KH
And all firmware should already be signed, you
are trying to extend the
chain-of-trust to a different processor on the system, which is _way_
beyond what UEFI is asking for, and beyond anything that anyone has ever
I really don't think these are necessary, does anyone else?
They are necessary. In terms of hardware most PCI devices are capable
of writing into RAM whereever they want to. Therefore the ability to load
altered firmware into a device is equivalent to the ability to alter RAM at
Given, that only manufacturers are able to guarantee the integrity of firmware
blobs¹, they must also provide the signatures. It escapes me, how a third
party signature raises security in this respect (other then providing a way to
ensure, that it wasn't tampered with *after* signage).
¹) Even that is rather optimistic, given real world scenarios..
This patchset provide a check mechanism in kernel and tools for sign
driver's firmware, it give a standard way to anyone(kernel community,
manufacturers...) for sign firmware. I think it's valuable for
On the other hand, the tool sign firmware when 'make firmware_install'
then we package *.sig file to kernel RPM or KMP. That means the chain of
trust extend to firmware signature when openSUSE build service build and
sign kernel/KMP with the same key.
If we trust the firmware files that were sent to kernel community or
openSUSE community by manufacturers, then we can trust the firmware
signature that will generated when build/sign RPMs on build service.
I mean, even the firmware signature provide by manufacturers, we still
need a standard and a mechanism in kernel for verify it. That's a part
of this patchset does.
Thanks a lot!
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org