[opensuse-kernel] [PATCH 0/4] Backported patches for support driver firmware sign
Patch-mainline: Not yet, reviewing (contributed by Takashi) Target: openSUSE 12.3 Test steps: + select the following kernel config: Enable loadable module support -> Module signature verification Require modules to be validly signed Which hash algorithm should modules be signed with? ---> Device Drivers ---> Generic Driver Options ---> Firmware signature verification (NEW) + mkinitrd need this patch [1] + build; make modules_install; make firmware_install; make install + check the /lib/modules/3.0.51-default/, should have *.sig file + We can also test manually sign a firmware file: # ./scripts/sign-file -f -v signing_key.priv signing_key.x509 /lib/firmware/rtl_nic/rtl8105e-1.fw Takashi's patch set of driver firmware sign is reviewing on upstream, I backported it to openSUSE 12.3 for more testing. Backported 4 patches for support driver firmware sign Driver firmware sign (from Takashi, reviewing on upstream): Not yet: 0001-firmware:_Add_the_firmware_signing_support_to_scripts_sign-file.patch 0002-firmware:_Add_-a_option_to_scripts_sign-file.patch 0003-firmware:_Add_support_for_signature_checks.patch 0004-firmware:_Install_firmware_signature_files_automatically.patch [1] Index: mkinitrd-2.4.2/scripts/setup-modules.sh =================================================================== --- mkinitrd-2.4.2.orig/scripts/setup-modules.sh +++ mkinitrd-2.4.2/scripts/setup-modules.sh @@ -375,6 +375,10 @@ for module in $resolved_modules; do has_firmware=true fi echo -n "$fw " + if test -e "$dir/$subdir/$fw.sig"; then + cp -p --parents "$_" "$tmp_mnt" + echo -n "$fw.sig " + fi fi done done -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Takashi Iwai
From: Takashi Iwai
From: Takashi Iwai
From: Takashi Iwai
On Wed, Jan 16, 2013 at 02:49:34PM +0800, Lee, Chun-Yi wrote:
Patch-mainline: Not yet, reviewing (contributed by Takashi) Target: openSUSE 12.3
Why do we want to add this feature to 12.3 when it isn't needed by anyone? And it's not accepted upstream either. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
於 二,2013-01-15 於 23:10 -0800,Greg KH 提到:
On Wed, Jan 16, 2013 at 02:49:34PM +0800, Lee, Chun-Yi wrote:
Patch-mainline: Not yet, reviewing (contributed by Takashi) Target: openSUSE 12.3
Why do we want to add this feature to 12.3 when it isn't needed by anyone? And it's not accepted upstream either.
thanks,
greg k-h
The purpose of this patch set is for sign driver firmware to avoid attacker change the firmware to attack system. Takashi sent patches to upstream for ask other experts' thinking. But, yes, upstream didn't accept it until now. 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
On Wed, Jan 16, 2013 at 03:44:02PM +0800, joeyli wrote:
於 二,2013-01-15 於 23:10 -0800,Greg KH 提到:
On Wed, Jan 16, 2013 at 02:49:34PM +0800, Lee, Chun-Yi wrote:
Patch-mainline: Not yet, reviewing (contributed by Takashi) Target: openSUSE 12.3
Why do we want to add this feature to 12.3 when it isn't needed by anyone? And it's not accepted upstream either.
thanks,
greg k-h
The purpose of this patch set is for sign driver firmware to avoid attacker change the firmware to attack system. Takashi sent patches to upstream for ask other experts' thinking.
But, yes, upstream didn't accept it until now.
Now? I don't see them in Linus's tree, do you? 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? greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
於 二,2013-01-15 於 23:55 -0800,Greg KH 提到:
On Wed, Jan 16, 2013 at 03:44:02PM +0800, joeyli wrote:
於 二,2013-01-15 於 23:10 -0800,Greg KH 提到:
On Wed, Jan 16, 2013 at 02:49:34PM +0800, Lee, Chun-Yi wrote:
Patch-mainline: Not yet, reviewing (contributed by Takashi) Target: openSUSE 12.3
Why do we want to add this feature to 12.3 when it isn't needed by anyone? And it's not accepted upstream either.
thanks,
greg k-h
The purpose of this patch set is for sign driver firmware to avoid attacker change the firmware to attack system. Takashi sent patches to upstream for ask other experts' thinking.
But, yes, upstream didn't accept it until now.
Now? I don't see them in Linus's tree, do you?
Sorry for it's my fault, upstream did NOT accept those patches.
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?
greg k-h
The driver firmware sign function dependent on kernel modules sign enabled. So, it's extend the kernel modules sign function in kernel. Like kernel module sign, this function doesn't depend to UEFI secure boot enabled, anyone can enable it on non-UEFI machine. Of course from secure boot view point... Do the driver firmware sign is for avoid attack against to firmware then causes Microsoft revoke our signature. 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
At Tue, 15 Jan 2013 23:55:02 -0800, Greg KH wrote:
On Wed, Jan 16, 2013 at 03:44:02PM +0800, joeyli wrote:
於 二,2013-01-15 於 23:10 -0800,Greg KH 提到:
On Wed, Jan 16, 2013 at 02:49:34PM +0800, Lee, Chun-Yi wrote:
Patch-mainline: Not yet, reviewing (contributed by Takashi) Target: openSUSE 12.3
Why do we want to add this feature to 12.3 when it isn't needed by anyone? And it's not accepted upstream either.
thanks,
greg k-h
The purpose of this patch set is for sign driver firmware to avoid attacker change the firmware to attack system. Takashi sent patches to upstream for ask other experts' thinking.
But, yes, upstream didn't accept it until now.
Now? I don't see them in Linus's tree, do you?
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.
... so are many lockdown patches, too :)
I really don't think these are necessary, does anyone else?
Well, when this issue was discussed on ML, people (e.g. mjg) agreed that this would be a thing good-to-have, but certainly in a low priority. Whether to mandate this in secure boot mode is still an open question, I myself am not sure, too. But, one strong argument is that the CPU microcode is handled as a normal firmware file on Linux, thus it can be an attack vector. (And apart from that, having a capability for checking the validity of firmware files is a benefit, too.) thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, Jan 16, 2013 at 09:24:20AM +0100, Takashi Iwai wrote:
At Tue, 15 Jan 2013 23:55:02 -0800, Greg KH wrote:
On Wed, Jan 16, 2013 at 03:44:02PM +0800, joeyli wrote:
於 二,2013-01-15 於 23:10 -0800,Greg KH 提到:
On Wed, Jan 16, 2013 at 02:49:34PM +0800, Lee, Chun-Yi wrote:
Patch-mainline: Not yet, reviewing (contributed by Takashi) Target: openSUSE 12.3
Why do we want to add this feature to 12.3 when it isn't needed by anyone? And it's not accepted upstream either.
thanks,
greg k-h
The purpose of this patch set is for sign driver firmware to avoid attacker change the firmware to attack system. Takashi sent patches to upstream for ask other experts' thinking.
But, yes, upstream didn't accept it until now.
Now? I don't see them in Linus's tree, do you?
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.
... so are many lockdown patches, too :)
All of them in fact, which is why most of them aren't accepted upstream :)
I really don't think these are necessary, does anyone else?
Well, when this issue was discussed on ML, people (e.g. mjg) agreed that this would be a thing good-to-have, but certainly in a low priority.
Whether to mandate this in secure boot mode is still an open question, I myself am not sure, too. But, one strong argument is that the CPU microcode is handled as a normal firmware file on Linux, thus it can be an attack vector.
(And apart from that, having a capability for checking the validity of firmware files is a benefit, too.)
Sure, it's a "nice" feature, but why add it to openSUSE when it isn't accepted upstream and no one is asking for it? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
At Wed, 16 Jan 2013 18:01:10 -0800, Greg KH wrote:
On Wed, Jan 16, 2013 at 09:24:20AM +0100, Takashi Iwai wrote:
At Tue, 15 Jan 2013 23:55:02 -0800, Greg KH wrote:
On Wed, Jan 16, 2013 at 03:44:02PM +0800, joeyli wrote:
於 二,2013-01-15 於 23:10 -0800,Greg KH 提到:
On Wed, Jan 16, 2013 at 02:49:34PM +0800, Lee, Chun-Yi wrote:
Patch-mainline: Not yet, reviewing (contributed by Takashi) Target: openSUSE 12.3
Why do we want to add this feature to 12.3 when it isn't needed by anyone? And it's not accepted upstream either.
thanks,
greg k-h
The purpose of this patch set is for sign driver firmware to avoid attacker change the firmware to attack system. Takashi sent patches to upstream for ask other experts' thinking.
But, yes, upstream didn't accept it until now.
Now? I don't see them in Linus's tree, do you?
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.
... so are many lockdown patches, too :)
All of them in fact, which is why most of them aren't accepted upstream :)
I really don't think these are necessary, does anyone else?
Well, when this issue was discussed on ML, people (e.g. mjg) agreed that this would be a thing good-to-have, but certainly in a low priority.
Whether to mandate this in secure boot mode is still an open question, I myself am not sure, too. But, one strong argument is that the CPU microcode is handled as a normal firmware file on Linux, thus it can be an attack vector.
(And apart from that, having a capability for checking the validity of firmware files is a benefit, too.)
Sure, it's a "nice" feature, but why add it to openSUSE when it isn't accepted upstream and no one is asking for it?
OK, what about the other lockdown patches? From your standpoint, should they (the ones that aren't in upstream) be neither included to openSUSE kernel? If the condition is simply "upstream or not", I'd agree with you about openSUSE kernel inclusion. It's more maintainable to keep the openSUSE kernel close to the upstream as much as possible. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Thu, Jan 17, 2013 at 07:39:15AM +0100, Takashi Iwai wrote:
At Wed, 16 Jan 2013 18:01:10 -0800, Greg KH wrote:
On Wed, Jan 16, 2013 at 09:24:20AM +0100, Takashi Iwai wrote:
At Tue, 15 Jan 2013 23:55:02 -0800, Greg KH wrote:
On Wed, Jan 16, 2013 at 03:44:02PM +0800, joeyli wrote:
於 二,2013-01-15 於 23:10 -0800,Greg KH 提到:
On Wed, Jan 16, 2013 at 02:49:34PM +0800, Lee, Chun-Yi wrote: > Patch-mainline: Not yet, reviewing (contributed by Takashi) > Target: openSUSE 12.3
Why do we want to add this feature to 12.3 when it isn't needed by anyone? And it's not accepted upstream either.
thanks,
greg k-h
The purpose of this patch set is for sign driver firmware to avoid attacker change the firmware to attack system. Takashi sent patches to upstream for ask other experts' thinking.
But, yes, upstream didn't accept it until now.
Now? I don't see them in Linus's tree, do you?
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.
... so are many lockdown patches, too :)
All of them in fact, which is why most of them aren't accepted upstream :)
I really don't think these are necessary, does anyone else?
Well, when this issue was discussed on ML, people (e.g. mjg) agreed that this would be a thing good-to-have, but certainly in a low priority.
Whether to mandate this in secure boot mode is still an open question, I myself am not sure, too. But, one strong argument is that the CPU microcode is handled as a normal firmware file on Linux, thus it can be an attack vector.
(And apart from that, having a capability for checking the validity of firmware files is a benefit, too.)
Sure, it's a "nice" feature, but why add it to openSUSE when it isn't accepted upstream and no one is asking for it?
OK, what about the other lockdown patches? From your standpoint, should they (the ones that aren't in upstream) be neither included to openSUSE kernel?
I would vote for "upstream or not".
If the condition is simply "upstream or not", I'd agree with you about openSUSE kernel inclusion. It's more maintainable to keep the openSUSE kernel close to the upstream as much as possible.
Especially given that it is updated for every release that comes out, making updating these patches a burden on the kernel maintainers. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
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. Regards Oliver -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On Wed, Jan 16, 2013 at 10:09:29AM +0100, Oliver Neukum wrote:
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.
Again, this has nothing to do with UEFI or anything else. I understand the wish to feel "better" about signing firmware, but this isn't something that is required by anyone. Also, watch out, some firmware files don't allow you to "modify" them, so the signatures need to be kept elsewhere, hopefully this patchset does that. And this seems like a pretty late feature that isn't accepted upstream, why add it to openSUSE given that there doesn't seem to be a requirement by anyone for this? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
於 三,2013-01-16 於 18:00 -0800,Greg KH 提到:
On Wed, Jan 16, 2013 at 10:09:29AM +0100, Oliver Neukum wrote:
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.
Again, this has nothing to do with UEFI or anything else. I understand the wish to feel "better" about signing firmware, but this isn't something that is required by anyone.
Also, watch out, some firmware files don't allow you to "modify" them, so the signatures need to be kept elsewhere, hopefully this patchset does that.
Yes, this patchset generate signature from firmware and put to a separate .sig file.
And this seems like a pretty late feature that isn't accepted upstream, why add it to openSUSE given that there doesn't seem to be a requirement by anyone for this?
thanks,
greg k-h
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
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.. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
於 四,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
participants (6)
-
Greg KH
-
Hans-Peter Jansen
-
joeyli
-
Lee, Chun-Yi
-
Oliver Neukum
-
Takashi Iwai