[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 <tiwai@suse.de> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing Target: openSUSE 12.3 Add -f option to sign-file script for generating a firmware signature file. A firmware signature file contains a pretty similar structure like a signed module but in a different order (because it's a separate file while the module signature is embedded at the tail of unsigned module contents). The file consists of - the magic string - the signature information, which is identical with the module signature - signer's name - key id - signature bytes Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Lee, Chun-Yi <jlee@suse.com> --- scripts/sign-file | 48 +++++++++++++++++++++++++++++++++++------------- 1 file changed, 35 insertions(+), 13 deletions(-) --- a/scripts/sign-file +++ b/scripts/sign-file @@ -4,30 +4,40 @@ # # Format: # -# ./scripts/sign-file [-v] <key> <x509> <module> [<dest>] +# ./scripts/sign-file [-v] [-f] <key> <x509> <module> [<dest>] # # use strict; use FileHandle; use IPC::Open2; +use Getopt::Long; -my $verbose = 0; -if ($#ARGV >= 0 && $ARGV[0] eq "-v") { - $verbose = 1; - shift; +sub usage() +{ + print "Format: ./scripts/sign-file [options] <key> <x509> <module> [<dest>] + -v verbose output + -f create a firmware signature file +"; + exit; } -die "Format: ./scripts/sign-file [-v] <key> <x509> <module> [<dest>]\n" - if ($#ARGV != 2 && $#ARGV != 3); +my $verbose = 0; +my $sign_fw = 0; + +GetOptions( + 'v|verbose' => \$verbose, + 'f|firmware' => \$sign_fw) || usage(); +usage() if ($#ARGV != 2 && $#ARGV != 3); my $private_key = $ARGV[0]; my $x509 = $ARGV[1]; my $module = $ARGV[2]; -my $dest = ($#ARGV == 3) ? $ARGV[3] : $ARGV[2] . "~"; +my $dest = $ARGV[3] ? $ARGV[3] : $ARGV[2] . ($sign_fw ? ".sig" : "~"); +my $mode_name = $sign_fw ? "firmware" : "module"; die "Can't read private key\n" unless (-r $private_key); die "Can't read X.509 certificate\n" unless (-r $x509); -die "Can't read module\n" unless (-r $module); +die "Can't read $mode_name\n" unless (-r $module); # # Read the kernel configuration @@ -393,7 +403,9 @@ die "openssl rsautl died: $?" if ($? >> # my $unsigned_module = read_file($module); -my $magic_number = "~Module signature appended~\n"; +my $magic_number = $sign_fw ? + "~Linux firmware signature~\n" : + "~Module signature appended~\n"; my $info = pack("CCCCCxxxN", $algo, $hash, $id_type, @@ -402,7 +414,7 @@ my $info = pack("CCCCCxxxN", length($signature)); if ($verbose) { - print "Size of unsigned module: ", length($unsigned_module), "\n"; + print "Size of unsigned $mode_name: ", length($unsigned_module), "\n"; print "Size of signer's name : ", length($signers_name), "\n"; print "Size of key identifier : ", length($key_identifier), "\n"; print "Size of signature : ", length($signature), "\n"; @@ -414,7 +426,16 @@ if ($verbose) { open(FD, ">$dest") || die $dest; binmode FD; -print FD +if ($sign_fw) { + print FD + $magic_number, + $info, + $signers_name, + $key_identifier, + $signature + ; +} else { + print FD $unsigned_module, $signers_name, $key_identifier, @@ -422,8 +443,9 @@ print FD $info, $magic_number ; +} close FD || die $dest; -if ($#ARGV != 3) { +if (!$sign_fw && $#ARGV != 3) { rename($dest, $module) || die $module; } -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Takashi Iwai <tiwai@suse.de> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing Target: openSUSE 12.3 Add a new option -a to sign-file for specifying the hash algorithm to sign a file, to make it working without .config file. This will be useful signing external module or firmware files. Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Lee, Chun-Yi <jlee@suse.com> --- scripts/sign-file | 40 ++++++++++++++++++++++++++++------------ 1 file changed, 28 insertions(+), 12 deletions(-) --- a/scripts/sign-file +++ b/scripts/sign-file @@ -4,7 +4,7 @@ # # Format: # -# ./scripts/sign-file [-v] [-f] <key> <x509> <module> [<dest>] +# ./scripts/sign-file [-v] [-f] [-a algo] <key> <x509> <module> [<dest>] # # use strict; @@ -17,16 +17,19 @@ sub usage() print "Format: ./scripts/sign-file [options] <key> <x509> <module> [<dest>] -v verbose output -f create a firmware signature file + -a algo specify hash algorithm "; exit; } my $verbose = 0; +my $hashalgo = ""; my $sign_fw = 0; GetOptions( 'v|verbose' => \$verbose, - 'f|firmware' => \$sign_fw) || usage(); + 'f|firmware' => \$sign_fw, + 'a|algo=s' => \$hashalgo) || usage(); usage() if ($#ARGV != 2 && $#ARGV != 3); my $private_key = $ARGV[0]; @@ -42,10 +45,7 @@ die "Can't read $mode_name\n" unless (-r # # Read the kernel configuration # -my %config = ( - CONFIG_MODULE_SIG_SHA512 => 1 - ); - +my %config; if (-r ".config") { open(FD, "<.config") || die ".config"; while (<FD>) { @@ -56,6 +56,22 @@ if (-r ".config") { close(FD); } +if ($hashalgo eq "") { + if (exists $config{"CONFIG_MODULE_SIG_SHA1"}) { + $hashalgo="sha1"; + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA224"}) { + $hashalgo="sha224"; + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA256"}) { + $hashalgo="sha256"; + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA384"}) { + $hashalgo="sha384"; + } elsif (exists $config{"CONFIG_MODULE_SIG_SHA512"}) { + $hashalgo="sha512"; + } else { + die "Can't determine hash algorithm"; + } +} + # # Function to read the contents of a file into a variable. # @@ -332,35 +348,35 @@ my $id_type = 1; # Identifier type: X.50 # Digest the data # my ($dgst, $prologue) = (); -if (exists $config{"CONFIG_MODULE_SIG_SHA1"}) { +if ($hashalgo eq "sha1") { $prologue = pack("C*", 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x0E, 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14); $dgst = "-sha1"; $hash = 2; -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA224"}) { +} elsif ($hashalgo eq "sha224") { $prologue = pack("C*", 0x30, 0x2d, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05, 0x00, 0x04, 0x1C); $dgst = "-sha224"; $hash = 7; -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA256"}) { +} elsif ($hashalgo eq "sha256") { $prologue = pack("C*", 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20); $dgst = "-sha256"; $hash = 4; -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA384"}) { +} elsif ($hashalgo eq "sha384") { $prologue = pack("C*", 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, 0x00, 0x04, 0x30); $dgst = "-sha384"; $hash = 5; -} elsif (exists $config{"CONFIG_MODULE_SIG_SHA512"}) { +} elsif ($hashalgo eq "sha512") { $prologue = pack("C*", 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, @@ -368,7 +384,7 @@ if (exists $config{"CONFIG_MODULE_SIG_SH $dgst = "-sha512"; $hash = 6; } else { - die "Can't determine hash algorithm"; + die "Invalid hash algorithm $hashalgo"; } # -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Takashi Iwai <tiwai@suse.de> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing Target: openSUSE 12.3 Add a feature to check the firmware signature, specified via Kconfig CONFIG_FIRMWARE_SIG. The signature check is performed only for the direct fw loading without udev. If sig_enforce is set but no firmware file is found in fs, request_firmware*() returns an error for now. It would be possible to improve this situation, e.g. by adding an extra request of signature via yet another uevent, but I'm too lazy to implement it and also skeptical whether it's needed. On a kernel with CONFIG_FIRMWARE_SIG=y and sig_enforce=1 set, when no firmware signature is present or the signature doesn't match, the kernel rejects such a firmware and proceeds to the next possible one. With sig_enforce=0, a firmware is loaded even if no signature is found or the signature doesn't match, but it taints the kernel with TAINT_USER. This behavior is similar like the signed module loading. Last to be noted, in this version, the firmware signature support depends on CONFIG_MODULE_SIG, that is, the system requires the module support for now. Joey Lee: Replace include linux/export.h with linux/module.h for v3.0 kernel. Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Lee, Chun-Yi <jlee@suse.com> --- drivers/base/Kconfig | 6 +++ drivers/base/firmware_class.c | 78 ++++++++++++++++++++++++++++++++++++++---- include/linux/firmware.h | 7 +++ kernel/module_signing.c | 63 +++++++++++++++++++++++++++++++++ 4 files changed, 147 insertions(+), 7 deletions(-) --- a/drivers/base/Kconfig +++ b/drivers/base/Kconfig @@ -145,6 +145,12 @@ config EXTRA_FIRMWARE_DIR this option you can point it elsewhere, such as /lib/firmware/ or some other directory containing the firmware files. +config FIRMWARE_SIG + bool "Firmware signature verification" + depends on FW_LOADER && MODULE_SIG + help + Enable firmware signature check. + config DEBUG_DRIVER bool "Driver Core verbose debug messages" depends on DEBUG_KERNEL --- a/drivers/base/firmware_class.c +++ b/drivers/base/firmware_class.c @@ -36,6 +36,11 @@ MODULE_AUTHOR("Manuel Estrada Sainz"); MODULE_DESCRIPTION("Multi purpose firmware loading support"); MODULE_LICENSE("GPL"); +#ifdef CONFIG_FIRMWARE_SIG +static bool sig_enforce; +module_param(sig_enforce, bool, 0644); +#endif + /* Builtin firmware support */ #ifdef CONFIG_FW_LOADER @@ -289,7 +294,7 @@ static noinline long fw_file_size(struct return st.size; } -static bool fw_read_file_contents(struct file *file, struct firmware_buf *fw_buf) +static bool fw_read_file_contents(struct file *file, void **bufp, size_t *sizep) { long size; char *buf; @@ -304,14 +309,42 @@ static bool fw_read_file_contents(struct vfree(buf); return false; } - fw_buf->data = buf; - fw_buf->size = size; + *bufp = buf; + *sizep = size; return true; } +#ifdef CONFIG_FIRMWARE_SIG +static int verify_sig_file(struct firmware_buf *buf, const char *path) +{ + const unsigned long markerlen = sizeof(FIRMWARE_SIG_STRING) - 1; + struct file *file; + void *sig_data; + size_t sig_size; + int ret; + + file = filp_open(path, O_RDONLY, 0); + if (IS_ERR(file)) + return -ENOKEY; + + ret = fw_read_file_contents(file, &sig_data, &sig_size); + fput(file); + if (!ret) + return -ENOKEY; + if (sig_size <= markerlen || + memcmp(sig_data, FIRMWARE_SIG_STRING, markerlen)) + return -EBADMSG; + ret = fw_verify_sig(buf->data, buf->size, + sig_data + markerlen, sig_size - markerlen); + pr_debug("verified signature %s: %d\n", path, ret); + vfree(sig_data); + return ret; +} +#endif /* CONFIG_FIRMWARE_SIG */ + static bool fw_get_filesystem_firmware(struct firmware_buf *buf) { - int i; + int i, ret; bool success = false; char *path = __getname(); @@ -322,10 +355,30 @@ static bool fw_get_filesystem_firmware(s file = filp_open(path, O_RDONLY, 0); if (IS_ERR(file)) continue; - success = fw_read_file_contents(file, buf); + success = fw_read_file_contents(file, &buf->data, &buf->size); fput(file); - if (success) - break; + if (!success) + continue; +#ifdef CONFIG_FIRMWARE_SIG + snprintf(path, PATH_MAX, "%s/%s.sig", fw_path[i], buf->fw_id); + ret = verify_sig_file(buf, path); + if (ret < 0) { + if (ret == -ENOENT) + pr_err("Cannot find firmware signature %s\n", + path); + else + pr_err("Invalid firmware signature %s\n", path); + if (sig_enforce) { + vfree(buf->data); + buf->data = NULL; + buf->size = 0; + success = false; + continue; + } + add_taint(TAINT_USER); + } +#endif /* CONFIG_FIRMWARE_SIG */ + break; } __putname(path); return success; @@ -875,6 +928,17 @@ static int _request_firmware_load(struct goto handle_fw; } +#ifdef CONFIG_FIRMWARE_SIG + /* FIXME: we don't handle signature check for fw loaded via udev */ + if (sig_enforce) { + pr_err("Cannot find firmware file %s; aborting fw loading\n", + buf->fw_id); + fw_load_abort(fw_priv); + direct_load = 1; + goto handle_fw; + } +#endif + /* fall back on userspace loading */ buf->fmt = PAGE_BUF; --- a/include/linux/firmware.h +++ b/include/linux/firmware.h @@ -79,4 +79,11 @@ static inline int uncache_firmware(const } #endif +#ifdef CONFIG_FIRMWARE_SIG +#define FIRMWARE_SIG_STRING "~Linux firmware signature~\n" +/* defined in kernel/module_signing.c */ +int fw_verify_sig(const void *fw_data, size_t fw_size, + const void *sig_data, size_t sig_size); +#endif + #endif --- a/kernel/module_signing.c +++ b/kernel/module_signing.c @@ -11,6 +11,7 @@ #include <linux/kernel.h> #include <linux/err.h> +#include <linux/module.h> #include <crypto/public_key.h> #include <crypto/hash.h> #include <keys/asymmetric-type.h> @@ -247,3 +248,65 @@ error_put_key: pr_devel("<==%s() = %d\n", __func__, ret); return ret; } + +#ifdef CONFIG_FIRMWARE_SIG +/* + * Verify the firmware signature, similar like module signature check + * but it's stored in a separate file + */ +int fw_verify_sig(const void *fw_data, size_t fw_size, + const void *sig_data, size_t sig_size) +{ + struct public_key_signature *pks; + struct module_signature ms; + struct key *key; + size_t sig_len; + int ret; + + if (sig_size <= sizeof(ms)) + return -EBADMSG; + + memcpy(&ms, sig_data, sizeof(ms)); + sig_data += sizeof(ms); + sig_size -= sizeof(ms); + + sig_len = be32_to_cpu(ms.sig_len); + if (sig_size < sig_len + (size_t)ms.signer_len + ms.key_id_len) + return -EBADMSG; + + /* For the moment, only support RSA and X.509 identifiers */ + if (ms.algo != PKEY_ALGO_RSA || + ms.id_type != PKEY_ID_X509) + return -ENOPKG; + + if (ms.hash >= PKEY_HASH__LAST || + !pkey_hash_algo[ms.hash]) + return -ENOPKG; + + key = request_asymmetric_key(sig_data, ms.signer_len, + sig_data + ms.signer_len, ms.key_id_len); + if (IS_ERR(key)) + return PTR_ERR(key); + + pks = mod_make_digest(ms.hash, fw_data, fw_size); + if (IS_ERR(pks)) { + ret = PTR_ERR(pks); + goto error_put_key; + } + + sig_data += ms.signer_len + ms.key_id_len; + ret = mod_extract_mpi_array(pks, sig_data, sig_len); + if (ret < 0) + goto error_free_pks; + + ret = verify_signature(key, pks); + +error_free_pks: + mpi_free(pks->rsa.s); + kfree(pks); +error_put_key: + key_put(key); + return ret; +} +EXPORT_SYMBOL_GPL(fw_verify_sig); +#endif /* CONFIG_FIRMWARE_SIG */ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
From: Takashi Iwai <tiwai@suse.de> Git-commit: Not yet, reviewing Patch-mainline: Not yet, reviewing Target: openSUSE 12.3 ... when CONFIG_FIRMWARE_SIG is set. Signed-off-by: Takashi Iwai <tiwai@suse.de> Acked-by: Lee, Chun-Yi <jlee@suse.com> --- Makefile | 6 ++++++ scripts/Makefile.fwinst | 18 ++++++++++++++++-- 2 files changed, 22 insertions(+), 2 deletions(-) --- a/Makefile +++ b/Makefile @@ -755,6 +755,12 @@ mod_sign_cmd = true endif export mod_sign_cmd +ifeq ($(CONFIG_FIRMWARE_SIG),y) +fw_sign_cmd = perl $(srctree)/scripts/sign-file -f $(MODSECKEY) $(MODPUBKEY) +else +fw_sign_cmd = true +endif +export fw_sign_cmd ifeq ($(KBUILD_EXTMOD),) core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/ --- a/scripts/Makefile.fwinst +++ b/scripts/Makefile.fwinst @@ -29,6 +29,20 @@ installed-mod-fw := $(addprefix $(INSTAL installed-fw := $(addprefix $(INSTALL_FW_PATH)/,$(fw-shipped-all)) installed-fw-dirs := $(sort $(dir $(installed-fw))) $(INSTALL_FW_PATH)/./ +ifeq ($(CONFIG_FIRMWARE_SIG),y) +installed-fw-sig := $(patsubst %,%.sig, $(installed-fw)) +installed-mod-fw-sig := $(patsubst %,%.sig, $(installed-mod-fw)) +else +installed-fw-sig := +installed-mod-fw-sig := +endif + +quiet_cmd_fwsig = FWSIG $@ + cmd_fwsig = $(fw_sign_cmd) $(patsubst %.sig,%,$@) $@ + +%.sig: % + $(call cmd,fwsig) + # Workaround for make < 3.81, where .SECONDEXPANSION doesn't work. PHONY += $(INSTALL_FW_PATH)/$$(%) install-all-dirs $(INSTALL_FW_PATH)/$$(%): install-all-dirs @@ -49,9 +63,9 @@ PHONY += __fw_install __fw_modinst FORC .PHONY: $(PHONY) -__fw_install: $(installed-fw) +__fw_install: $(installed-fw) $(installed-fw-sig) -__fw_modinst: $(installed-mod-fw) +__fw_modinst: $(installed-mod-fw) $(installed-mod-fw-sig) @: __fw_modbuild: $(addprefix $(obj)/,$(mod-fw)) -- 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 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