於 四，2013-01-17 於 16:30 +0100，Hans-Peter Jansen 提到：
Am Mittwoch, 16. Januar 2013, 10:09:29 schrieb Oliver Neukum:
On Tuesday 15 January 2013 23:55:02 Greg KH wrote:
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 suggested.
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 will.
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).
Cheers, Pete
¹) 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 manufacturers. 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! Joey Lee -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org