[RFC v1 00/12] kernel/firmware/wireless: firmware digital signature checks

[RFC v1 00/12] kernel/firmware/wireless: firmware digital signature checks

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

We've been discussing for a while now replacing the 802.11 Linux
CRDA agent [0] by in-kernel functionality. This series address
what is required to begin to take this serious. It is split by
a few series of patches, I've linked them all as otherwise folks
might get confused. I clarify what is what below and by a prefix
on each patch.

  * first set: [1-4] few fixes and core changes in order to consider digital
    firmware signature support. Please consider these for integration. Patch
    2 generalizes module signing as system data signing and can very likely
    just be ignored unles the second set seems more reasonable to start
    considering. One of these goes as a stable fix.

  * second set: [5-6] kernel firmware signature support. These should be
    considered for discussion. We need to figure out what if/how we want
    to deal with this. Its obviously needed to replace userspace agents
    with similar requirements, so its a requirement for the last set.

  * third set: [7-12] firmware API simplication / extensibility rewrite,
    more for discussion than anything as we keep extending it, then it
    starts piggy backing alternative crypto requirements. Its intended to
    provide as an example how subsystems might differ in their requirements
    for files in userspace. The driver changes should be completely ignored
    as real patches -- these are just example patches of *how* to use the
    APIs. The cfg80211 change should be reviewed as its how we could
    end up providing optional alternative cyrpto requirements and extensions,
    should we go down that road.

I did consider LSM hooks -- but since we already have one for firmware
and since this re-uses the firmware API, the same LSM hooks can be used
for distributions that want that over digital signature verification
of speficic firmware / system data files.

My own preference and recommendations:

This has served more as an excercise to review the firmware module code
and to get us to more seriously consider whether or not we want
digital firmware signature checks. I think we should seriously
consider replacing the custom CRDA key option with kernel distribution 
private / public keys used for module signing, and for further
customization simply let folks use LSM hooks / LSM modules for
customization as well as the Integrity Measurement Architecture (IMA) [1].

We *should* seriously consider digital firmware signature support,
how we want to phase usermode helper suppport and how we want to
enable extensions of the firmware API as the current code isn't
practical for extensions/growth. In so far a digital firmware
signature support I think it might be a good idea to support different
files for signatures and request those in addition to the actual
firmware, any reason not to do it that way?

Please note that the binary firmware format still needs to be
addresed. I don't have time for that though so I hope that this
will help suffice to at least address the requirements to replace
CRDA in-kernel.

[0] https://wireless.wiki.kernel.org/en/developers/regulatory/crda
[1] http://sourceforge.net/p/linux-ima/wiki/Home/

Luis R. Rodriguez (12):
  1  - kernel/params.c: export param_ops_bool_enable_only
  2  - kernel: generalize module signing as system data signing
  3  - crypto: qat - address recursive dependency when fw signing is enabled
  4  - firmware: fix possible use after free on name on asynchronous request

  5  - firmware: add firmware signature checking support
  6  - firmware: generalize "firmware" as "system data" helpers

  7  - firmware: add generic system data helpers with signature support
  8  - p54spi: use sysdata_file_request() for EEPROM optional system data
  9  - p54: use sysdata_file_request() and sysdata_file_request_async()
  10 - ath9k_htc: use sysdata_file_request() and sysdata_file_request_async()
  11 - iwlwifi: use sysdata_file_request() and sysdata_file_request_async()
  12 - cfg80211: request for regulatory system data file

 drivers/base/Kconfig                           |  16 ++
 drivers/base/firmware_class.c                  | 318 ++++++++++++++++++++++++-
 drivers/crypto/qat/Kconfig                     |   2 +-
 drivers/net/wireless/ath/ath9k/hif_usb.c       |  62 +++--
 drivers/net/wireless/iwlwifi/iwl-drv.c         |  24 +-
 drivers/net/wireless/p54/eeprom.c              |   1 -
 drivers/net/wireless/p54/fwio.c                |   4 +-
 drivers/net/wireless/p54/led.c                 |   1 -
 drivers/net/wireless/p54/main.c                |   1 -
 drivers/net/wireless/p54/p54.h                 |   4 +-
 drivers/net/wireless/p54/p54pci.c              |  19 +-
 drivers/net/wireless/p54/p54pci.h              |   2 +-
 drivers/net/wireless/p54/p54spi.c              |  68 +++---
 drivers/net/wireless/p54/p54spi.h              |   2 +-
 drivers/net/wireless/p54/p54usb.c              |  14 +-
 drivers/net/wireless/p54/p54usb.h              |   2 +-
 drivers/net/wireless/p54/txrx.c                |   1 -
 include/linux/firmware.h                       |   1 +
 include/linux/sysdata.h                        | 200 ++++++++++++++++
 init/Kconfig                                   |  22 +-
 kernel/Makefile                                |   2 +-
 kernel/module-internal.h                       |  12 -
 kernel/module.c                                |   4 +-
 kernel/params.c                                |   1 +
 kernel/{module_signing.c => sysdata_signing.c} |  77 +++---
 kernel/system_keyring.c                        |   2 +-
 net/wireless/Kconfig                           |  20 ++
 net/wireless/reg.c                             |  85 +++++--
 scripts/sign-file                              |  20 +-
 29 files changed, 804 insertions(+), 183 deletions(-)
 create mode 100644 include/linux/sysdata.h
 delete mode 100644 kernel/module-internal.h
 rename kernel/{module_signing.c => sysdata_signing.c} (76%)

-- 
2.3.2.209.gd67f9d5.dirty

[wireless-regdb] [RFC v1 00/12] kernel/firmware/wireless: firmware digital signature checks

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

We've been discussing for a while now replacing the 802.11 Linux
CRDA agent [0] by in-kernel functionality. This series address
what is required to begin to take this serious. It is split by
a few series of patches, I've linked them all as otherwise folks
might get confused. I clarify what is what below and by a prefix
on each patch.

  * first set: [1-4] few fixes and core changes in order to consider digital
    firmware signature support. Please consider these for integration. Patch
    2 generalizes module signing as system data signing and can very likely
    just be ignored unles the second set seems more reasonable to start
    considering. One of these goes as a stable fix.

  * second set: [5-6] kernel firmware signature support. These should be
    considered for discussion. We need to figure out what if/how we want
    to deal with this. Its obviously needed to replace userspace agents
    with similar requirements, so its a requirement for the last set.

  * third set: [7-12] firmware API simplication / extensibility rewrite,
    more for discussion than anything as we keep extending it, then it
    starts piggy backing alternative crypto requirements. Its intended to
    provide as an example how subsystems might differ in their requirements
    for files in userspace. The driver changes should be completely ignored
    as real patches -- these are just example patches of *how* to use the
    APIs. The cfg80211 change should be reviewed as its how we could
    end up providing optional alternative cyrpto requirements and extensions,
    should we go down that road.

I did consider LSM hooks -- but since we already have one for firmware
and since this re-uses the firmware API, the same LSM hooks can be used
for distributions that want that over digital signature verification
of speficic firmware / system data files.

My own preference and recommendations:

This has served more as an excercise to review the firmware module code
and to get us to more seriously consider whether or not we want
digital firmware signature checks. I think we should seriously
consider replacing the custom CRDA key option with kernel distribution 
private / public keys used for module signing, and for further
customization simply let folks use LSM hooks / LSM modules for
customization as well as the Integrity Measurement Architecture (IMA) [1].

We *should* seriously consider digital firmware signature support,
how we want to phase usermode helper suppport and how we want to
enable extensions of the firmware API as the current code isn't
practical for extensions/growth. In so far a digital firmware
signature support I think it might be a good idea to support different
files for signatures and request those in addition to the actual
firmware, any reason not to do it that way?

Please note that the binary firmware format still needs to be
addresed. I don't have time for that though so I hope that this
will help suffice to at least address the requirements to replace
CRDA in-kernel.

[0] https://wireless.wiki.kernel.org/en/developers/regulatory/crda
[1] http://sourceforge.net/p/linux-ima/wiki/Home/

Luis R. Rodriguez (12):
  1  - kernel/params.c: export param_ops_bool_enable_only
  2  - kernel: generalize module signing as system data signing
  3  - crypto: qat - address recursive dependency when fw signing is enabled
  4  - firmware: fix possible use after free on name on asynchronous request

  5  - firmware: add firmware signature checking support
  6  - firmware: generalize "firmware" as "system data" helpers

  7  - firmware: add generic system data helpers with signature support
  8  - p54spi: use sysdata_file_request() for EEPROM optional system data
  9  - p54: use sysdata_file_request() and sysdata_file_request_async()
  10 - ath9k_htc: use sysdata_file_request() and sysdata_file_request_async()
  11 - iwlwifi: use sysdata_file_request() and sysdata_file_request_async()
  12 - cfg80211: request for regulatory system data file

 drivers/base/Kconfig                           |  16 ++
 drivers/base/firmware_class.c                  | 318 ++++++++++++++++++++++++-
 drivers/crypto/qat/Kconfig                     |   2 +-
 drivers/net/wireless/ath/ath9k/hif_usb.c       |  62 +++--
 drivers/net/wireless/iwlwifi/iwl-drv.c         |  24 +-
 drivers/net/wireless/p54/eeprom.c              |   1 -
 drivers/net/wireless/p54/fwio.c                |   4 +-
 drivers/net/wireless/p54/led.c                 |   1 -
 drivers/net/wireless/p54/main.c                |   1 -
 drivers/net/wireless/p54/p54.h                 |   4 +-
 drivers/net/wireless/p54/p54pci.c              |  19 +-
 drivers/net/wireless/p54/p54pci.h              |   2 +-
 drivers/net/wireless/p54/p54spi.c              |  68 +++---
 drivers/net/wireless/p54/p54spi.h              |   2 +-
 drivers/net/wireless/p54/p54usb.c              |  14 +-
 drivers/net/wireless/p54/p54usb.h              |   2 +-
 drivers/net/wireless/p54/txrx.c                |   1 -
 include/linux/firmware.h                       |   1 +
 include/linux/sysdata.h                        | 200 ++++++++++++++++
 init/Kconfig                                   |  22 +-
 kernel/Makefile                                |   2 +-
 kernel/module-internal.h                       |  12 -
 kernel/module.c                                |   4 +-
 kernel/params.c                                |   1 +
 kernel/{module_signing.c => sysdata_signing.c} |  77 +++---
 kernel/system_keyring.c                        |   2 +-
 net/wireless/Kconfig                           |  20 ++
 net/wireless/reg.c                             |  85 +++++--
 scripts/sign-file                              |  20 +-
 29 files changed, 804 insertions(+), 183 deletions(-)
 create mode 100644 include/linux/sysdata.h
 delete mode 100644 kernel/module-internal.h
 rename kernel/{module_signing.c => sysdata_signing.c} (76%)

-- 
2.3.2.209.gd67f9d5.dirty


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

[PATCH v1 01/12] kernel/params.c: export param_ops_bool_enable_only

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

This will grant access to this helper to code built as modules.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 kernel/params.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/params.c b/kernel/params.c
index a62dbf8..807f3d4 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -364,6 +364,7 @@ const struct kernel_param_ops param_ops_bool_enable_only = {
 	.set = param_set_bool_enable_only,
 	.get = param_get_bool,
 };
+EXPORT_SYMBOL_GPL(param_ops_bool_enable_only);
 
 /* This one must be bool. */
 int param_set_invbool(const char *val, const struct kernel_param *kp)
-- 
2.3.2.209.gd67f9d5.dirty

[wireless-regdb] [PATCH v1 01/12] kernel/params.c: export param_ops_bool_enable_only

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

This will grant access to this helper to code built as modules.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 kernel/params.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/params.c b/kernel/params.c
index a62dbf8..807f3d4 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -364,6 +364,7 @@ const struct kernel_param_ops param_ops_bool_enable_only = {
 	.set = param_set_bool_enable_only,
 	.get = param_get_bool,
 };
+EXPORT_SYMBOL_GPL(param_ops_bool_enable_only);
 
 /* This one must be bool. */
 int param_set_invbool(const char *val, const struct kernel_param *kp)
-- 
2.3.2.209.gd67f9d5.dirty


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 01/12] kernel/params.c: export param_ops_bool_enable_only

[Rusty Russell]

"Luis R. Rodriguez" <mcgrof@do-not-panic.com> writes:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> This will grant access to this helper to code built as modules.
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Ming Lei <ming.lei@canonical.com>
> Cc: Seth Forshee <seth.forshee@canonical.com>
> Cc: Kyle McMartin <kyle@kernel.org>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>

Applied,
Rusty.

Re: [wireless-regdb] [PATCH v1 01/12] kernel/params.c: export param_ops_bool_enable_only

[Rusty Russell]

"Luis R. Rodriguez" <mcgrof@do-not-panic.com> writes:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> This will grant access to this helper to code built as modules.
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Ming Lei <ming.lei@canonical.com>
> Cc: Seth Forshee <seth.forshee@canonical.com>
> Cc: Kyle McMartin <kyle@kernel.org>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>

Applied,
Rusty.

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

[PATCH v1 02/12] kernel: generalize module signing as system data signing

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

This generalizes the module signing code as helpers, we do
this as we'll later re-use this same code for firmware and
other system data signing.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 init/Kconfig                                     | 22 ++++---
 kernel/Makefile                                  |  2 +-
 kernel/module.c                                  |  4 +-
 kernel/{module-internal.h => sysdata-internal.h} |  4 +-
 kernel/{module_signing.c => sysdata_signing.c}   | 76 ++++++++++++------------
 kernel/system_keyring.c                          |  2 +-
 6 files changed, 57 insertions(+), 53 deletions(-)
 rename kernel/{module-internal.h => sysdata-internal.h} (79%)
 rename kernel/{module_signing.c => sysdata_signing.c} (76%)

diff --git a/init/Kconfig b/init/Kconfig
index f5dbc6d..862d5ad7 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1769,6 +1769,18 @@ config BASE_SMALL
 	default 0 if BASE_FULL
 	default 1 if !BASE_FULL
 
+config SYSDATA_SIG
+	def_bool y
+	select SYSTEM_TRUSTED_KEYRING
+	select KEYS
+	select CRYPTO
+	select ASYMMETRIC_KEY_TYPE
+	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
+	select PUBLIC_KEY_ALGO_RSA
+	select ASN1
+	select OID_REGISTRY
+	select X509_CERTIFICATE_PARSER
+
 menuconfig MODULES
 	bool "Enable loadable module support"
 	option modules
@@ -1842,15 +1854,7 @@ config MODULE_SRCVERSION_ALL
 config MODULE_SIG
 	bool "Module signature verification"
 	depends on MODULES
-	select SYSTEM_TRUSTED_KEYRING
-	select KEYS
-	select CRYPTO
-	select ASYMMETRIC_KEY_TYPE
-	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
-	select PUBLIC_KEY_ALGO_RSA
-	select ASN1
-	select OID_REGISTRY
-	select X509_CERTIFICATE_PARSER
+	select SYSDATA_SIG
 	help
 	  Check modules for valid signatures upon load: the signature
 	  is simply appended to the module. For more information see
diff --git a/kernel/Makefile b/kernel/Makefile
index 1408b33..e24c9d6 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -45,7 +45,7 @@ endif
 obj-$(CONFIG_UID16) += uid16.o
 obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o
 obj-$(CONFIG_MODULES) += module.o
-obj-$(CONFIG_MODULE_SIG) += module_signing.o
+obj-$(CONFIG_SYSDATA_SIG) += sysdata_signing.o
 obj-$(CONFIG_KALLSYMS) += kallsyms.o
 obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
 obj-$(CONFIG_KEXEC) += kexec.o
diff --git a/kernel/module.c b/kernel/module.c
index 23b2b65..eb61c10 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -60,7 +60,7 @@
 #include <linux/pfn.h>
 #include <linux/bsearch.h>
 #include <uapi/linux/module.h>
-#include "module-internal.h"
+#include "sysdata-internal.h"
 
 #define CREATE_TRACE_POINTS
 #include <trace/events/module.h>
@@ -2404,7 +2404,7 @@ static int module_sig_check(struct load_info *info)
 	    memcmp(mod + info->len - markerlen, MODULE_SIG_STRING, markerlen) == 0) {
 		/* We truncate the module to discard the signature */
 		info->len -= markerlen;
-		err = mod_verify_sig(mod, &info->len);
+		err = sysdata_verify_sig(mod, &info->len);
 	}
 
 	if (!err) {
diff --git a/kernel/module-internal.h b/kernel/sysdata-internal.h
similarity index 79%
rename from kernel/module-internal.h
rename to kernel/sysdata-internal.h
index 915e123..0aa573e 100644
--- a/kernel/module-internal.h
+++ b/kernel/sysdata-internal.h
@@ -1,4 +1,4 @@
-/* Module internals
+/* System Data internals
  *
  * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowells@redhat.com)
@@ -9,4 +9,4 @@
  * 2 of the Licence, or (at your option) any later version.
  */
 
-extern int mod_verify_sig(const void *mod, unsigned long *_modlen);
+extern int sysdata_verify_sig(const void *data, unsigned long *_len);
diff --git a/kernel/module_signing.c b/kernel/sysdata_signing.c
similarity index 76%
rename from kernel/module_signing.c
rename to kernel/sysdata_signing.c
index be5b8fa..8ba09aa 100644
--- a/kernel/module_signing.c
+++ b/kernel/sysdata_signing.c
@@ -1,4 +1,4 @@
-/* Module signature checker
+/* System Data signature checker
  *
  * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowells@redhat.com)
@@ -15,10 +15,10 @@
 #include <crypto/hash.h>
 #include <keys/asymmetric-type.h>
 #include <keys/system_keyring.h>
-#include "module-internal.h"
+#include "sysdata-internal.h"
 
 /*
- * Module signature information block.
+ * System Data signature information block.
  *
  * The constituents of the signature section are, in order:
  *
@@ -27,7 +27,7 @@
  *	- Signature data
  *	- Information block
  */
-struct module_signature {
+struct sysdata_signature {
 	u8	algo;		/* Public-key crypto algorithm [enum pkey_algo] */
 	u8	hash;		/* Digest algorithm [enum hash_algo] */
 	u8	id_type;	/* Key identifier type [enum pkey_id_type] */
@@ -38,11 +38,11 @@ struct module_signature {
 };
 
 /*
- * Digest the module contents.
+ * Digest the system data contents.
  */
-static struct public_key_signature *mod_make_digest(enum hash_algo hash,
-						    const void *mod,
-						    unsigned long modlen)
+static struct public_key_signature *data_make_digest(enum hash_algo hash,
+						    const void *data,
+						    unsigned long len)
 {
 	struct public_key_signature *pks;
 	struct crypto_shash *tfm;
@@ -51,7 +51,7 @@ static struct public_key_signature *mod_make_digest(enum hash_algo hash,
 	int ret;
 
 	pr_devel("==>%s()\n", __func__);
-	
+
 	/* Allocate the hashing algorithm we're going to need and find out how
 	 * big the hash operational data will be.
 	 */
@@ -82,7 +82,7 @@ static struct public_key_signature *mod_make_digest(enum hash_algo hash,
 	if (ret < 0)
 		goto error;
 
-	ret = crypto_shash_finup(desc, mod, modlen, pks->digest);
+	ret = crypto_shash_finup(desc, data, len, pks->digest);
 	if (ret < 0)
 		goto error;
 
@@ -105,8 +105,8 @@ error_no_pks:
  *
  * RSA signatures only have one MPI, so currently we only read one.
  */
-static int mod_extract_mpi_array(struct public_key_signature *pks,
-				 const void *data, size_t len)
+static int data_extract_mpi_array(struct public_key_signature *pks,
+				  const void *data, size_t len)
 {
 	size_t nbytes;
 	MPI mpi;
@@ -161,7 +161,7 @@ static struct key *request_asymmetric_key(const char *signer, size_t signer_len,
 	key = keyring_search(make_key_ref(system_trusted_keyring, 1),
 			     &key_type_asymmetric, id);
 	if (IS_ERR(key))
-		pr_warn("Request for unknown module key '%s' err %ld\n",
+		pr_warn("Request for unknown system data key '%s' err %ld\n",
 			id, PTR_ERR(key));
 	kfree(id);
 
@@ -182,58 +182,58 @@ static struct key *request_asymmetric_key(const char *signer, size_t signer_len,
 }
 
 /*
- * Verify the signature on a module.
+ * Verify the signature on system data.
  */
-int mod_verify_sig(const void *mod, unsigned long *_modlen)
+int sysdata_verify_sig(const void *data, unsigned long *_len)
 {
 	struct public_key_signature *pks;
-	struct module_signature ms;
+	struct sysdata_signature ds;
 	struct key *key;
 	const void *sig;
-	size_t modlen = *_modlen, sig_len;
+	size_t len = *_len, sig_len;
 	int ret;
 
-	pr_devel("==>%s(,%zu)\n", __func__, modlen);
+	pr_devel("==>%s(,%zu)\n", __func__, len);
 
-	if (modlen <= sizeof(ms))
+	if (len <= sizeof(ds))
 		return -EBADMSG;
 
-	memcpy(&ms, mod + (modlen - sizeof(ms)), sizeof(ms));
-	modlen -= sizeof(ms);
+	memcpy(&ds, data + (len - sizeof(ds)), sizeof(ds));
+	len -= sizeof(ds);
 
-	sig_len = be32_to_cpu(ms.sig_len);
-	if (sig_len >= modlen)
+	sig_len = be32_to_cpu(ds.sig_len);
+	if (sig_len >= len)
 		return -EBADMSG;
-	modlen -= sig_len;
-	if ((size_t)ms.signer_len + ms.key_id_len >= modlen)
+	len -= sig_len;
+	if ((size_t)ds.signer_len + ds.key_id_len >= len)
 		return -EBADMSG;
-	modlen -= (size_t)ms.signer_len + ms.key_id_len;
+	len -= (size_t)ds.signer_len + ds.key_id_len;
 
-	*_modlen = modlen;
-	sig = mod + modlen;
+	*_len = len;
+	sig = data + len;
 
 	/* For the moment, only support RSA and X.509 identifiers */
-	if (ms.algo != PKEY_ALGO_RSA ||
-	    ms.id_type != PKEY_ID_X509)
+	if (ds.algo != PKEY_ALGO_RSA ||
+	    ds.id_type != PKEY_ID_X509)
 		return -ENOPKG;
 
-	if (ms.hash >= PKEY_HASH__LAST ||
-	    !hash_algo_name[ms.hash])
+	if (ds.hash >= PKEY_HASH__LAST ||
+	    !hash_algo_name[ds.hash])
 		return -ENOPKG;
 
-	key = request_asymmetric_key(sig, ms.signer_len,
-				     sig + ms.signer_len, ms.key_id_len);
+	key = request_asymmetric_key(sig, ds.signer_len,
+				     sig + ds.signer_len, ds.key_id_len);
 	if (IS_ERR(key))
 		return PTR_ERR(key);
 
-	pks = mod_make_digest(ms.hash, mod, modlen);
+	pks = data_make_digest(ds.hash, data, len);
 	if (IS_ERR(pks)) {
 		ret = PTR_ERR(pks);
 		goto error_put_key;
 	}
 
-	ret = mod_extract_mpi_array(pks, sig + ms.signer_len + ms.key_id_len,
-				    sig_len);
+	ret = data_extract_mpi_array(pks, sig + ds.signer_len + ds.key_id_len,
+				     sig_len);
 	if (ret < 0)
 		goto error_free_pks;
 
@@ -246,5 +246,5 @@ error_free_pks:
 error_put_key:
 	key_put(key);
 	pr_devel("<==%s() = %d\n", __func__, ret);
-	return ret;	
+	return ret;
 }
diff --git a/kernel/system_keyring.c b/kernel/system_keyring.c
index 875f64e..1eb0c86 100644
--- a/kernel/system_keyring.c
+++ b/kernel/system_keyring.c
@@ -16,7 +16,7 @@
 #include <linux/err.h>
 #include <keys/asymmetric-type.h>
 #include <keys/system_keyring.h>
-#include "module-internal.h"
+#include "sysdata-internal.h"
 
 struct key *system_trusted_keyring;
 EXPORT_SYMBOL_GPL(system_trusted_keyring);
-- 
2.3.2.209.gd67f9d5.dirty

[wireless-regdb] [PATCH v1 02/12] kernel: generalize module signing as system data signing

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

This generalizes the module signing code as helpers, we do
this as we'll later re-use this same code for firmware and
other system data signing.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 init/Kconfig                                     | 22 ++++---
 kernel/Makefile                                  |  2 +-
 kernel/module.c                                  |  4 +-
 kernel/{module-internal.h => sysdata-internal.h} |  4 +-
 kernel/{module_signing.c => sysdata_signing.c}   | 76 ++++++++++++------------
 kernel/system_keyring.c                          |  2 +-
 6 files changed, 57 insertions(+), 53 deletions(-)
 rename kernel/{module-internal.h => sysdata-internal.h} (79%)
 rename kernel/{module_signing.c => sysdata_signing.c} (76%)

diff --git a/init/Kconfig b/init/Kconfig
index f5dbc6d..862d5ad7 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1769,6 +1769,18 @@ config BASE_SMALL
 	default 0 if BASE_FULL
 	default 1 if !BASE_FULL
 
+config SYSDATA_SIG
+	def_bool y
+	select SYSTEM_TRUSTED_KEYRING
+	select KEYS
+	select CRYPTO
+	select ASYMMETRIC_KEY_TYPE
+	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
+	select PUBLIC_KEY_ALGO_RSA
+	select ASN1
+	select OID_REGISTRY
+	select X509_CERTIFICATE_PARSER
+
 menuconfig MODULES
 	bool "Enable loadable module support"
 	option modules
@@ -1842,15 +1854,7 @@ config MODULE_SRCVERSION_ALL
 config MODULE_SIG
 	bool "Module signature verification"
 	depends on MODULES
-	select SYSTEM_TRUSTED_KEYRING
-	select KEYS
-	select CRYPTO
-	select ASYMMETRIC_KEY_TYPE
-	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
-	select PUBLIC_KEY_ALGO_RSA
-	select ASN1
-	select OID_REGISTRY
-	select X509_CERTIFICATE_PARSER
+	select SYSDATA_SIG
 	help
 	  Check modules for valid signatures upon load: the signature
 	  is simply appended to the module. For more information see
diff --git a/kernel/Makefile b/kernel/Makefile
index 1408b33..e24c9d6 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -45,7 +45,7 @@ endif
 obj-$(CONFIG_UID16) += uid16.o
 obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o
 obj-$(CONFIG_MODULES) += module.o
-obj-$(CONFIG_MODULE_SIG) += module_signing.o
+obj-$(CONFIG_SYSDATA_SIG) += sysdata_signing.o
 obj-$(CONFIG_KALLSYMS) += kallsyms.o
 obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
 obj-$(CONFIG_KEXEC) += kexec.o
diff --git a/kernel/module.c b/kernel/module.c
index 23b2b65..eb61c10 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -60,7 +60,7 @@
 #include <linux/pfn.h>
 #include <linux/bsearch.h>
 #include <uapi/linux/module.h>
-#include "module-internal.h"
+#include "sysdata-internal.h"
 
 #define CREATE_TRACE_POINTS
 #include <trace/events/module.h>
@@ -2404,7 +2404,7 @@ static int module_sig_check(struct load_info *info)
 	    memcmp(mod + info->len - markerlen, MODULE_SIG_STRING, markerlen) == 0) {
 		/* We truncate the module to discard the signature */
 		info->len -= markerlen;
-		err = mod_verify_sig(mod, &info->len);
+		err = sysdata_verify_sig(mod, &info->len);
 	}
 
 	if (!err) {
diff --git a/kernel/module-internal.h b/kernel/sysdata-internal.h
similarity index 79%
rename from kernel/module-internal.h
rename to kernel/sysdata-internal.h
index 915e123..0aa573e 100644
--- a/kernel/module-internal.h
+++ b/kernel/sysdata-internal.h
@@ -1,4 +1,4 @@
-/* Module internals
+/* System Data internals
  *
  * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowells@redhat.com)
@@ -9,4 +9,4 @@
  * 2 of the Licence, or (at your option) any later version.
  */
 
-extern int mod_verify_sig(const void *mod, unsigned long *_modlen);
+extern int sysdata_verify_sig(const void *data, unsigned long *_len);
diff --git a/kernel/module_signing.c b/kernel/sysdata_signing.c
similarity index 76%
rename from kernel/module_signing.c
rename to kernel/sysdata_signing.c
index be5b8fa..8ba09aa 100644
--- a/kernel/module_signing.c
+++ b/kernel/sysdata_signing.c
@@ -1,4 +1,4 @@
-/* Module signature checker
+/* System Data signature checker
  *
  * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowells@redhat.com)
@@ -15,10 +15,10 @@
 #include <crypto/hash.h>
 #include <keys/asymmetric-type.h>
 #include <keys/system_keyring.h>
-#include "module-internal.h"
+#include "sysdata-internal.h"
 
 /*
- * Module signature information block.
+ * System Data signature information block.
  *
  * The constituents of the signature section are, in order:
  *
@@ -27,7 +27,7 @@
  *	- Signature data
  *	- Information block
  */
-struct module_signature {
+struct sysdata_signature {
 	u8	algo;		/* Public-key crypto algorithm [enum pkey_algo] */
 	u8	hash;		/* Digest algorithm [enum hash_algo] */
 	u8	id_type;	/* Key identifier type [enum pkey_id_type] */
@@ -38,11 +38,11 @@ struct module_signature {
 };
 
 /*
- * Digest the module contents.
+ * Digest the system data contents.
  */
-static struct public_key_signature *mod_make_digest(enum hash_algo hash,
-						    const void *mod,
-						    unsigned long modlen)
+static struct public_key_signature *data_make_digest(enum hash_algo hash,
+						    const void *data,
+						    unsigned long len)
 {
 	struct public_key_signature *pks;
 	struct crypto_shash *tfm;
@@ -51,7 +51,7 @@ static struct public_key_signature *mod_make_digest(enum hash_algo hash,
 	int ret;
 
 	pr_devel("==>%s()\n", __func__);
-	
+
 	/* Allocate the hashing algorithm we're going to need and find out how
 	 * big the hash operational data will be.
 	 */
@@ -82,7 +82,7 @@ static struct public_key_signature *mod_make_digest(enum hash_algo hash,
 	if (ret < 0)
 		goto error;
 
-	ret = crypto_shash_finup(desc, mod, modlen, pks->digest);
+	ret = crypto_shash_finup(desc, data, len, pks->digest);
 	if (ret < 0)
 		goto error;
 
@@ -105,8 +105,8 @@ error_no_pks:
  *
  * RSA signatures only have one MPI, so currently we only read one.
  */
-static int mod_extract_mpi_array(struct public_key_signature *pks,
-				 const void *data, size_t len)
+static int data_extract_mpi_array(struct public_key_signature *pks,
+				  const void *data, size_t len)
 {
 	size_t nbytes;
 	MPI mpi;
@@ -161,7 +161,7 @@ static struct key *request_asymmetric_key(const char *signer, size_t signer_len,
 	key = keyring_search(make_key_ref(system_trusted_keyring, 1),
 			     &key_type_asymmetric, id);
 	if (IS_ERR(key))
-		pr_warn("Request for unknown module key '%s' err %ld\n",
+		pr_warn("Request for unknown system data key '%s' err %ld\n",
 			id, PTR_ERR(key));
 	kfree(id);
 
@@ -182,58 +182,58 @@ static struct key *request_asymmetric_key(const char *signer, size_t signer_len,
 }
 
 /*
- * Verify the signature on a module.
+ * Verify the signature on system data.
  */
-int mod_verify_sig(const void *mod, unsigned long *_modlen)
+int sysdata_verify_sig(const void *data, unsigned long *_len)
 {
 	struct public_key_signature *pks;
-	struct module_signature ms;
+	struct sysdata_signature ds;
 	struct key *key;
 	const void *sig;
-	size_t modlen = *_modlen, sig_len;
+	size_t len = *_len, sig_len;
 	int ret;
 
-	pr_devel("==>%s(,%zu)\n", __func__, modlen);
+	pr_devel("==>%s(,%zu)\n", __func__, len);
 
-	if (modlen <= sizeof(ms))
+	if (len <= sizeof(ds))
 		return -EBADMSG;
 
-	memcpy(&ms, mod + (modlen - sizeof(ms)), sizeof(ms));
-	modlen -= sizeof(ms);
+	memcpy(&ds, data + (len - sizeof(ds)), sizeof(ds));
+	len -= sizeof(ds);
 
-	sig_len = be32_to_cpu(ms.sig_len);
-	if (sig_len >= modlen)
+	sig_len = be32_to_cpu(ds.sig_len);
+	if (sig_len >= len)
 		return -EBADMSG;
-	modlen -= sig_len;
-	if ((size_t)ms.signer_len + ms.key_id_len >= modlen)
+	len -= sig_len;
+	if ((size_t)ds.signer_len + ds.key_id_len >= len)
 		return -EBADMSG;
-	modlen -= (size_t)ms.signer_len + ms.key_id_len;
+	len -= (size_t)ds.signer_len + ds.key_id_len;
 
-	*_modlen = modlen;
-	sig = mod + modlen;
+	*_len = len;
+	sig = data + len;
 
 	/* For the moment, only support RSA and X.509 identifiers */
-	if (ms.algo != PKEY_ALGO_RSA ||
-	    ms.id_type != PKEY_ID_X509)
+	if (ds.algo != PKEY_ALGO_RSA ||
+	    ds.id_type != PKEY_ID_X509)
 		return -ENOPKG;
 
-	if (ms.hash >= PKEY_HASH__LAST ||
-	    !hash_algo_name[ms.hash])
+	if (ds.hash >= PKEY_HASH__LAST ||
+	    !hash_algo_name[ds.hash])
 		return -ENOPKG;
 
-	key = request_asymmetric_key(sig, ms.signer_len,
-				     sig + ms.signer_len, ms.key_id_len);
+	key = request_asymmetric_key(sig, ds.signer_len,
+				     sig + ds.signer_len, ds.key_id_len);
 	if (IS_ERR(key))
 		return PTR_ERR(key);
 
-	pks = mod_make_digest(ms.hash, mod, modlen);
+	pks = data_make_digest(ds.hash, data, len);
 	if (IS_ERR(pks)) {
 		ret = PTR_ERR(pks);
 		goto error_put_key;
 	}
 
-	ret = mod_extract_mpi_array(pks, sig + ms.signer_len + ms.key_id_len,
-				    sig_len);
+	ret = data_extract_mpi_array(pks, sig + ds.signer_len + ds.key_id_len,
+				     sig_len);
 	if (ret < 0)
 		goto error_free_pks;
 
@@ -246,5 +246,5 @@ error_free_pks:
 error_put_key:
 	key_put(key);
 	pr_devel("<==%s() = %d\n", __func__, ret);
-	return ret;	
+	return ret;
 }
diff --git a/kernel/system_keyring.c b/kernel/system_keyring.c
index 875f64e..1eb0c86 100644
--- a/kernel/system_keyring.c
+++ b/kernel/system_keyring.c
@@ -16,7 +16,7 @@
 #include <linux/err.h>
 #include <keys/asymmetric-type.h>
 #include <keys/system_keyring.h>
-#include "module-internal.h"
+#include "sysdata-internal.h"
 
 struct key *system_trusted_keyring;
 EXPORT_SYMBOL_GPL(system_trusted_keyring);
-- 
2.3.2.209.gd67f9d5.dirty


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 02/12] kernel: generalize module signing as system data signing

[Rusty Russell]

"Luis R. Rodriguez" <mcgrof@do-not-panic.com> writes:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> This generalizes the module signing code as helpers, we do
> this as we'll later re-use this same code for firmware and
> other system data signing.

Acked-by: Rusty Russell <rusty@rustcorp.com.au> (module parts)

Thanks,
Rusty.

> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Ming Lei <ming.lei@canonical.com>
> Cc: Seth Forshee <seth.forshee@canonical.com>
> Cc: Kyle McMartin <kyle@kernel.org>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
>  init/Kconfig                                     | 22 ++++---
>  kernel/Makefile                                  |  2 +-
>  kernel/module.c                                  |  4 +-
>  kernel/{module-internal.h => sysdata-internal.h} |  4 +-
>  kernel/{module_signing.c => sysdata_signing.c}   | 76 ++++++++++++------------
>  kernel/system_keyring.c                          |  2 +-
>  6 files changed, 57 insertions(+), 53 deletions(-)
>  rename kernel/{module-internal.h => sysdata-internal.h} (79%)
>  rename kernel/{module_signing.c => sysdata_signing.c} (76%)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index f5dbc6d..862d5ad7 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1769,6 +1769,18 @@ config BASE_SMALL
>  	default 0 if BASE_FULL
>  	default 1 if !BASE_FULL
>  
> +config SYSDATA_SIG
> +	def_bool y
> +	select SYSTEM_TRUSTED_KEYRING
> +	select KEYS
> +	select CRYPTO
> +	select ASYMMETRIC_KEY_TYPE
> +	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> +	select PUBLIC_KEY_ALGO_RSA
> +	select ASN1
> +	select OID_REGISTRY
> +	select X509_CERTIFICATE_PARSER
> +
>  menuconfig MODULES
>  	bool "Enable loadable module support"
>  	option modules
> @@ -1842,15 +1854,7 @@ config MODULE_SRCVERSION_ALL
>  config MODULE_SIG
>  	bool "Module signature verification"
>  	depends on MODULES
> -	select SYSTEM_TRUSTED_KEYRING
> -	select KEYS
> -	select CRYPTO
> -	select ASYMMETRIC_KEY_TYPE
> -	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> -	select PUBLIC_KEY_ALGO_RSA
> -	select ASN1
> -	select OID_REGISTRY
> -	select X509_CERTIFICATE_PARSER
> +	select SYSDATA_SIG
>  	help
>  	  Check modules for valid signatures upon load: the signature
>  	  is simply appended to the module. For more information see
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 1408b33..e24c9d6 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -45,7 +45,7 @@ endif
>  obj-$(CONFIG_UID16) += uid16.o
>  obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o
>  obj-$(CONFIG_MODULES) += module.o
> -obj-$(CONFIG_MODULE_SIG) += module_signing.o
> +obj-$(CONFIG_SYSDATA_SIG) += sysdata_signing.o
>  obj-$(CONFIG_KALLSYMS) += kallsyms.o
>  obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
>  obj-$(CONFIG_KEXEC) += kexec.o
> diff --git a/kernel/module.c b/kernel/module.c
> index 23b2b65..eb61c10 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -60,7 +60,7 @@
>  #include <linux/pfn.h>
>  #include <linux/bsearch.h>
>  #include <uapi/linux/module.h>
> -#include "module-internal.h"
> +#include "sysdata-internal.h"
>  
>  #define CREATE_TRACE_POINTS
>  #include <trace/events/module.h>
> @@ -2404,7 +2404,7 @@ static int module_sig_check(struct load_info *info)
>  	    memcmp(mod + info->len - markerlen, MODULE_SIG_STRING, markerlen) == 0) {
>  		/* We truncate the module to discard the signature */
>  		info->len -= markerlen;
> -		err = mod_verify_sig(mod, &info->len);
> +		err = sysdata_verify_sig(mod, &info->len);
>  	}
>  
>  	if (!err) {
> diff --git a/kernel/module-internal.h b/kernel/sysdata-internal.h
> similarity index 79%
> rename from kernel/module-internal.h
> rename to kernel/sysdata-internal.h
> index 915e123..0aa573e 100644
> --- a/kernel/module-internal.h
> +++ b/kernel/sysdata-internal.h
> @@ -1,4 +1,4 @@
> -/* Module internals
> +/* System Data internals
>   *
>   * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
>   * Written by David Howells (dhowells@redhat.com)
> @@ -9,4 +9,4 @@
>   * 2 of the Licence, or (at your option) any later version.
>   */
>  
> -extern int mod_verify_sig(const void *mod, unsigned long *_modlen);
> +extern int sysdata_verify_sig(const void *data, unsigned long *_len);
> diff --git a/kernel/module_signing.c b/kernel/sysdata_signing.c
> similarity index 76%
> rename from kernel/module_signing.c
> rename to kernel/sysdata_signing.c
> index be5b8fa..8ba09aa 100644
> --- a/kernel/module_signing.c
> +++ b/kernel/sysdata_signing.c
> @@ -1,4 +1,4 @@
> -/* Module signature checker
> +/* System Data signature checker
>   *
>   * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
>   * Written by David Howells (dhowells@redhat.com)
> @@ -15,10 +15,10 @@
>  #include <crypto/hash.h>
>  #include <keys/asymmetric-type.h>
>  #include <keys/system_keyring.h>
> -#include "module-internal.h"
> +#include "sysdata-internal.h"
>  
>  /*
> - * Module signature information block.
> + * System Data signature information block.
>   *
>   * The constituents of the signature section are, in order:
>   *
> @@ -27,7 +27,7 @@
>   *	- Signature data
>   *	- Information block
>   */
> -struct module_signature {
> +struct sysdata_signature {
>  	u8	algo;		/* Public-key crypto algorithm [enum pkey_algo] */
>  	u8	hash;		/* Digest algorithm [enum hash_algo] */
>  	u8	id_type;	/* Key identifier type [enum pkey_id_type] */
> @@ -38,11 +38,11 @@ struct module_signature {
>  };
>  
>  /*
> - * Digest the module contents.
> + * Digest the system data contents.
>   */
> -static struct public_key_signature *mod_make_digest(enum hash_algo hash,
> -						    const void *mod,
> -						    unsigned long modlen)
> +static struct public_key_signature *data_make_digest(enum hash_algo hash,
> +						    const void *data,
> +						    unsigned long len)
>  {
>  	struct public_key_signature *pks;
>  	struct crypto_shash *tfm;
> @@ -51,7 +51,7 @@ static struct public_key_signature *mod_make_digest(enum hash_algo hash,
>  	int ret;
>  
>  	pr_devel("==>%s()\n", __func__);
> -	
> +
>  	/* Allocate the hashing algorithm we're going to need and find out how
>  	 * big the hash operational data will be.
>  	 */
> @@ -82,7 +82,7 @@ static struct public_key_signature *mod_make_digest(enum hash_algo hash,
>  	if (ret < 0)
>  		goto error;
>  
> -	ret = crypto_shash_finup(desc, mod, modlen, pks->digest);
> +	ret = crypto_shash_finup(desc, data, len, pks->digest);
>  	if (ret < 0)
>  		goto error;
>  
> @@ -105,8 +105,8 @@ error_no_pks:
>   *
>   * RSA signatures only have one MPI, so currently we only read one.
>   */
> -static int mod_extract_mpi_array(struct public_key_signature *pks,
> -				 const void *data, size_t len)
> +static int data_extract_mpi_array(struct public_key_signature *pks,
> +				  const void *data, size_t len)
>  {
>  	size_t nbytes;
>  	MPI mpi;
> @@ -161,7 +161,7 @@ static struct key *request_asymmetric_key(const char *signer, size_t signer_len,
>  	key = keyring_search(make_key_ref(system_trusted_keyring, 1),
>  			     &key_type_asymmetric, id);
>  	if (IS_ERR(key))
> -		pr_warn("Request for unknown module key '%s' err %ld\n",
> +		pr_warn("Request for unknown system data key '%s' err %ld\n",
>  			id, PTR_ERR(key));
>  	kfree(id);
>  
> @@ -182,58 +182,58 @@ static struct key *request_asymmetric_key(const char *signer, size_t signer_len,
>  }
>  
>  /*
> - * Verify the signature on a module.
> + * Verify the signature on system data.
>   */
> -int mod_verify_sig(const void *mod, unsigned long *_modlen)
> +int sysdata_verify_sig(const void *data, unsigned long *_len)
>  {
>  	struct public_key_signature *pks;
> -	struct module_signature ms;
> +	struct sysdata_signature ds;
>  	struct key *key;
>  	const void *sig;
> -	size_t modlen = *_modlen, sig_len;
> +	size_t len = *_len, sig_len;
>  	int ret;
>  
> -	pr_devel("==>%s(,%zu)\n", __func__, modlen);
> +	pr_devel("==>%s(,%zu)\n", __func__, len);
>  
> -	if (modlen <= sizeof(ms))
> +	if (len <= sizeof(ds))
>  		return -EBADMSG;
>  
> -	memcpy(&ms, mod + (modlen - sizeof(ms)), sizeof(ms));
> -	modlen -= sizeof(ms);
> +	memcpy(&ds, data + (len - sizeof(ds)), sizeof(ds));
> +	len -= sizeof(ds);
>  
> -	sig_len = be32_to_cpu(ms.sig_len);
> -	if (sig_len >= modlen)
> +	sig_len = be32_to_cpu(ds.sig_len);
> +	if (sig_len >= len)
>  		return -EBADMSG;
> -	modlen -= sig_len;
> -	if ((size_t)ms.signer_len + ms.key_id_len >= modlen)
> +	len -= sig_len;
> +	if ((size_t)ds.signer_len + ds.key_id_len >= len)
>  		return -EBADMSG;
> -	modlen -= (size_t)ms.signer_len + ms.key_id_len;
> +	len -= (size_t)ds.signer_len + ds.key_id_len;
>  
> -	*_modlen = modlen;
> -	sig = mod + modlen;
> +	*_len = len;
> +	sig = data + len;
>  
>  	/* For the moment, only support RSA and X.509 identifiers */
> -	if (ms.algo != PKEY_ALGO_RSA ||
> -	    ms.id_type != PKEY_ID_X509)
> +	if (ds.algo != PKEY_ALGO_RSA ||
> +	    ds.id_type != PKEY_ID_X509)
>  		return -ENOPKG;
>  
> -	if (ms.hash >= PKEY_HASH__LAST ||
> -	    !hash_algo_name[ms.hash])
> +	if (ds.hash >= PKEY_HASH__LAST ||
> +	    !hash_algo_name[ds.hash])
>  		return -ENOPKG;
>  
> -	key = request_asymmetric_key(sig, ms.signer_len,
> -				     sig + ms.signer_len, ms.key_id_len);
> +	key = request_asymmetric_key(sig, ds.signer_len,
> +				     sig + ds.signer_len, ds.key_id_len);
>  	if (IS_ERR(key))
>  		return PTR_ERR(key);
>  
> -	pks = mod_make_digest(ms.hash, mod, modlen);
> +	pks = data_make_digest(ds.hash, data, len);
>  	if (IS_ERR(pks)) {
>  		ret = PTR_ERR(pks);
>  		goto error_put_key;
>  	}
>  
> -	ret = mod_extract_mpi_array(pks, sig + ms.signer_len + ms.key_id_len,
> -				    sig_len);
> +	ret = data_extract_mpi_array(pks, sig + ds.signer_len + ds.key_id_len,
> +				     sig_len);
>  	if (ret < 0)
>  		goto error_free_pks;
>  
> @@ -246,5 +246,5 @@ error_free_pks:
>  error_put_key:
>  	key_put(key);
>  	pr_devel("<==%s() = %d\n", __func__, ret);
> -	return ret;	
> +	return ret;
>  }
> diff --git a/kernel/system_keyring.c b/kernel/system_keyring.c
> index 875f64e..1eb0c86 100644
> --- a/kernel/system_keyring.c
> +++ b/kernel/system_keyring.c
> @@ -16,7 +16,7 @@
>  #include <linux/err.h>
>  #include <keys/asymmetric-type.h>
>  #include <keys/system_keyring.h>
> -#include "module-internal.h"
> +#include "sysdata-internal.h"
>  
>  struct key *system_trusted_keyring;
>  EXPORT_SYMBOL_GPL(system_trusted_keyring);
> -- 
> 2.3.2.209.gd67f9d5.dirty

Re: [wireless-regdb] [PATCH v1 02/12] kernel: generalize module signing as system data signing

[Rusty Russell]

"Luis R. Rodriguez" <mcgrof@do-not-panic.com> writes:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> This generalizes the module signing code as helpers, we do
> this as we'll later re-use this same code for firmware and
> other system data signing.

Acked-by: Rusty Russell <rusty@rustcorp.com.au> (module parts)

Thanks,
Rusty.

> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Ming Lei <ming.lei@canonical.com>
> Cc: Seth Forshee <seth.forshee@canonical.com>
> Cc: Kyle McMartin <kyle@kernel.org>
> Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
> ---
>  init/Kconfig                                     | 22 ++++---
>  kernel/Makefile                                  |  2 +-
>  kernel/module.c                                  |  4 +-
>  kernel/{module-internal.h => sysdata-internal.h} |  4 +-
>  kernel/{module_signing.c => sysdata_signing.c}   | 76 ++++++++++++------------
>  kernel/system_keyring.c                          |  2 +-
>  6 files changed, 57 insertions(+), 53 deletions(-)
>  rename kernel/{module-internal.h => sysdata-internal.h} (79%)
>  rename kernel/{module_signing.c => sysdata_signing.c} (76%)
>
> diff --git a/init/Kconfig b/init/Kconfig
> index f5dbc6d..862d5ad7 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1769,6 +1769,18 @@ config BASE_SMALL
>  	default 0 if BASE_FULL
>  	default 1 if !BASE_FULL
>  
> +config SYSDATA_SIG
> +	def_bool y
> +	select SYSTEM_TRUSTED_KEYRING
> +	select KEYS
> +	select CRYPTO
> +	select ASYMMETRIC_KEY_TYPE
> +	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> +	select PUBLIC_KEY_ALGO_RSA
> +	select ASN1
> +	select OID_REGISTRY
> +	select X509_CERTIFICATE_PARSER
> +
>  menuconfig MODULES
>  	bool "Enable loadable module support"
>  	option modules
> @@ -1842,15 +1854,7 @@ config MODULE_SRCVERSION_ALL
>  config MODULE_SIG
>  	bool "Module signature verification"
>  	depends on MODULES
> -	select SYSTEM_TRUSTED_KEYRING
> -	select KEYS
> -	select CRYPTO
> -	select ASYMMETRIC_KEY_TYPE
> -	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> -	select PUBLIC_KEY_ALGO_RSA
> -	select ASN1
> -	select OID_REGISTRY
> -	select X509_CERTIFICATE_PARSER
> +	select SYSDATA_SIG
>  	help
>  	  Check modules for valid signatures upon load: the signature
>  	  is simply appended to the module. For more information see
> diff --git a/kernel/Makefile b/kernel/Makefile
> index 1408b33..e24c9d6 100644
> --- a/kernel/Makefile
> +++ b/kernel/Makefile
> @@ -45,7 +45,7 @@ endif
>  obj-$(CONFIG_UID16) += uid16.o
>  obj-$(CONFIG_SYSTEM_TRUSTED_KEYRING) += system_keyring.o system_certificates.o
>  obj-$(CONFIG_MODULES) += module.o
> -obj-$(CONFIG_MODULE_SIG) += module_signing.o
> +obj-$(CONFIG_SYSDATA_SIG) += sysdata_signing.o
>  obj-$(CONFIG_KALLSYMS) += kallsyms.o
>  obj-$(CONFIG_BSD_PROCESS_ACCT) += acct.o
>  obj-$(CONFIG_KEXEC) += kexec.o
> diff --git a/kernel/module.c b/kernel/module.c
> index 23b2b65..eb61c10 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -60,7 +60,7 @@
>  #include <linux/pfn.h>
>  #include <linux/bsearch.h>
>  #include <uapi/linux/module.h>
> -#include "module-internal.h"
> +#include "sysdata-internal.h"
>  
>  #define CREATE_TRACE_POINTS
>  #include <trace/events/module.h>
> @@ -2404,7 +2404,7 @@ static int module_sig_check(struct load_info *info)
>  	    memcmp(mod + info->len - markerlen, MODULE_SIG_STRING, markerlen) == 0) {
>  		/* We truncate the module to discard the signature */
>  		info->len -= markerlen;
> -		err = mod_verify_sig(mod, &info->len);
> +		err = sysdata_verify_sig(mod, &info->len);
>  	}
>  
>  	if (!err) {
> diff --git a/kernel/module-internal.h b/kernel/sysdata-internal.h
> similarity index 79%
> rename from kernel/module-internal.h
> rename to kernel/sysdata-internal.h
> index 915e123..0aa573e 100644
> --- a/kernel/module-internal.h
> +++ b/kernel/sysdata-internal.h
> @@ -1,4 +1,4 @@
> -/* Module internals
> +/* System Data internals
>   *
>   * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
>   * Written by David Howells (dhowells@redhat.com)
> @@ -9,4 +9,4 @@
>   * 2 of the Licence, or (at your option) any later version.
>   */
>  
> -extern int mod_verify_sig(const void *mod, unsigned long *_modlen);
> +extern int sysdata_verify_sig(const void *data, unsigned long *_len);
> diff --git a/kernel/module_signing.c b/kernel/sysdata_signing.c
> similarity index 76%
> rename from kernel/module_signing.c
> rename to kernel/sysdata_signing.c
> index be5b8fa..8ba09aa 100644
> --- a/kernel/module_signing.c
> +++ b/kernel/sysdata_signing.c
> @@ -1,4 +1,4 @@
> -/* Module signature checker
> +/* System Data signature checker
>   *
>   * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
>   * Written by David Howells (dhowells@redhat.com)
> @@ -15,10 +15,10 @@
>  #include <crypto/hash.h>
>  #include <keys/asymmetric-type.h>
>  #include <keys/system_keyring.h>
> -#include "module-internal.h"
> +#include "sysdata-internal.h"
>  
>  /*
> - * Module signature information block.
> + * System Data signature information block.
>   *
>   * The constituents of the signature section are, in order:
>   *
> @@ -27,7 +27,7 @@
>   *	- Signature data
>   *	- Information block
>   */
> -struct module_signature {
> +struct sysdata_signature {
>  	u8	algo;		/* Public-key crypto algorithm [enum pkey_algo] */
>  	u8	hash;		/* Digest algorithm [enum hash_algo] */
>  	u8	id_type;	/* Key identifier type [enum pkey_id_type] */
> @@ -38,11 +38,11 @@ struct module_signature {
>  };
>  
>  /*
> - * Digest the module contents.
> + * Digest the system data contents.
>   */
> -static struct public_key_signature *mod_make_digest(enum hash_algo hash,
> -						    const void *mod,
> -						    unsigned long modlen)
> +static struct public_key_signature *data_make_digest(enum hash_algo hash,
> +						    const void *data,
> +						    unsigned long len)
>  {
>  	struct public_key_signature *pks;
>  	struct crypto_shash *tfm;
> @@ -51,7 +51,7 @@ static struct public_key_signature *mod_make_digest(enum hash_algo hash,
>  	int ret;
>  
>  	pr_devel("==>%s()\n", __func__);
> -	
> +
>  	/* Allocate the hashing algorithm we're going to need and find out how
>  	 * big the hash operational data will be.
>  	 */
> @@ -82,7 +82,7 @@ static struct public_key_signature *mod_make_digest(enum hash_algo hash,
>  	if (ret < 0)
>  		goto error;
>  
> -	ret = crypto_shash_finup(desc, mod, modlen, pks->digest);
> +	ret = crypto_shash_finup(desc, data, len, pks->digest);
>  	if (ret < 0)
>  		goto error;
>  
> @@ -105,8 +105,8 @@ error_no_pks:
>   *
>   * RSA signatures only have one MPI, so currently we only read one.
>   */
> -static int mod_extract_mpi_array(struct public_key_signature *pks,
> -				 const void *data, size_t len)
> +static int data_extract_mpi_array(struct public_key_signature *pks,
> +				  const void *data, size_t len)
>  {
>  	size_t nbytes;
>  	MPI mpi;
> @@ -161,7 +161,7 @@ static struct key *request_asymmetric_key(const char *signer, size_t signer_len,
>  	key = keyring_search(make_key_ref(system_trusted_keyring, 1),
>  			     &key_type_asymmetric, id);
>  	if (IS_ERR(key))
> -		pr_warn("Request for unknown module key '%s' err %ld\n",
> +		pr_warn("Request for unknown system data key '%s' err %ld\n",
>  			id, PTR_ERR(key));
>  	kfree(id);
>  
> @@ -182,58 +182,58 @@ static struct key *request_asymmetric_key(const char *signer, size_t signer_len,
>  }
>  
>  /*
> - * Verify the signature on a module.
> + * Verify the signature on system data.
>   */
> -int mod_verify_sig(const void *mod, unsigned long *_modlen)
> +int sysdata_verify_sig(const void *data, unsigned long *_len)
>  {
>  	struct public_key_signature *pks;
> -	struct module_signature ms;
> +	struct sysdata_signature ds;
>  	struct key *key;
>  	const void *sig;
> -	size_t modlen = *_modlen, sig_len;
> +	size_t len = *_len, sig_len;
>  	int ret;
>  
> -	pr_devel("==>%s(,%zu)\n", __func__, modlen);
> +	pr_devel("==>%s(,%zu)\n", __func__, len);
>  
> -	if (modlen <= sizeof(ms))
> +	if (len <= sizeof(ds))
>  		return -EBADMSG;
>  
> -	memcpy(&ms, mod + (modlen - sizeof(ms)), sizeof(ms));
> -	modlen -= sizeof(ms);
> +	memcpy(&ds, data + (len - sizeof(ds)), sizeof(ds));
> +	len -= sizeof(ds);
>  
> -	sig_len = be32_to_cpu(ms.sig_len);
> -	if (sig_len >= modlen)
> +	sig_len = be32_to_cpu(ds.sig_len);
> +	if (sig_len >= len)
>  		return -EBADMSG;
> -	modlen -= sig_len;
> -	if ((size_t)ms.signer_len + ms.key_id_len >= modlen)
> +	len -= sig_len;
> +	if ((size_t)ds.signer_len + ds.key_id_len >= len)
>  		return -EBADMSG;
> -	modlen -= (size_t)ms.signer_len + ms.key_id_len;
> +	len -= (size_t)ds.signer_len + ds.key_id_len;
>  
> -	*_modlen = modlen;
> -	sig = mod + modlen;
> +	*_len = len;
> +	sig = data + len;
>  
>  	/* For the moment, only support RSA and X.509 identifiers */
> -	if (ms.algo != PKEY_ALGO_RSA ||
> -	    ms.id_type != PKEY_ID_X509)
> +	if (ds.algo != PKEY_ALGO_RSA ||
> +	    ds.id_type != PKEY_ID_X509)
>  		return -ENOPKG;
>  
> -	if (ms.hash >= PKEY_HASH__LAST ||
> -	    !hash_algo_name[ms.hash])
> +	if (ds.hash >= PKEY_HASH__LAST ||
> +	    !hash_algo_name[ds.hash])
>  		return -ENOPKG;
>  
> -	key = request_asymmetric_key(sig, ms.signer_len,
> -				     sig + ms.signer_len, ms.key_id_len);
> +	key = request_asymmetric_key(sig, ds.signer_len,
> +				     sig + ds.signer_len, ds.key_id_len);
>  	if (IS_ERR(key))
>  		return PTR_ERR(key);
>  
> -	pks = mod_make_digest(ms.hash, mod, modlen);
> +	pks = data_make_digest(ds.hash, data, len);
>  	if (IS_ERR(pks)) {
>  		ret = PTR_ERR(pks);
>  		goto error_put_key;
>  	}
>  
> -	ret = mod_extract_mpi_array(pks, sig + ms.signer_len + ms.key_id_len,
> -				    sig_len);
> +	ret = data_extract_mpi_array(pks, sig + ds.signer_len + ds.key_id_len,
> +				     sig_len);
>  	if (ret < 0)
>  		goto error_free_pks;
>  
> @@ -246,5 +246,5 @@ error_free_pks:
>  error_put_key:
>  	key_put(key);
>  	pr_devel("<==%s() = %d\n", __func__, ret);
> -	return ret;	
> +	return ret;
>  }
> diff --git a/kernel/system_keyring.c b/kernel/system_keyring.c
> index 875f64e..1eb0c86 100644
> --- a/kernel/system_keyring.c
> +++ b/kernel/system_keyring.c
> @@ -16,7 +16,7 @@
>  #include <linux/err.h>
>  #include <keys/asymmetric-type.h>
>  #include <keys/system_keyring.h>
> -#include "module-internal.h"
> +#include "sysdata-internal.h"
>  
>  struct key *system_trusted_keyring;
>  EXPORT_SYMBOL_GPL(system_trusted_keyring);
> -- 
> 2.3.2.209.gd67f9d5.dirty

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

[PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

We're going to add firmware module signing support, but when we do
this we end up with the following recursive dependency. Fix this by
just depending on FW_LOADER, which is typically always enabled
anyway.

mcgrof@ergon ~/linux-next (git::master)$ make allnoconfig
scripts/kconfig/conf  --allnoconfig Kconfig
crypto/Kconfig:15:error: recursive dependency detected!
crypto/Kconfig:15:      symbol CRYPTO is selected by SYSDATA_SIG
init/Kconfig:1880:      symbol SYSDATA_SIG is selected by FIRMWARE_SIG
drivers/base/Kconfig:88:        symbol FIRMWARE_SIG depends on FW_LOADER
drivers/base/Kconfig:80:        symbol FW_LOADER is selected by CRYPTO_DEV_QAT
drivers/crypto/qat/Kconfig:1:   symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
drivers/crypto/qat/Kconfig:13:  symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Cc: Bruce Allan <bruce.w.allan@intel.com>
Cc: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: John Griffin <john.griffin@intel.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/crypto/qat/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/qat/Kconfig b/drivers/crypto/qat/Kconfig
index 49bede2..9bea338 100644
--- a/drivers/crypto/qat/Kconfig
+++ b/drivers/crypto/qat/Kconfig
@@ -8,7 +8,7 @@ config CRYPTO_DEV_QAT
 	select CRYPTO_SHA1
 	select CRYPTO_SHA256
 	select CRYPTO_SHA512
-	select FW_LOADER
+	depends on FW_LOADER
 
 config CRYPTO_DEV_QAT_DH895xCC
 	tristate "Support for Intel(R) DH895xCC"
-- 
2.3.2.209.gd67f9d5.dirty

[wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

We're going to add firmware module signing support, but when we do
this we end up with the following recursive dependency. Fix this by
just depending on FW_LOADER, which is typically always enabled
anyway.

mcgrof@ergon ~/linux-next (git::master)$ make allnoconfig
scripts/kconfig/conf  --allnoconfig Kconfig
crypto/Kconfig:15:error: recursive dependency detected!
crypto/Kconfig:15:      symbol CRYPTO is selected by SYSDATA_SIG
init/Kconfig:1880:      symbol SYSDATA_SIG is selected by FIRMWARE_SIG
drivers/base/Kconfig:88:        symbol FIRMWARE_SIG depends on FW_LOADER
drivers/base/Kconfig:80:        symbol FW_LOADER is selected by CRYPTO_DEV_QAT
drivers/crypto/qat/Kconfig:1:   symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
drivers/crypto/qat/Kconfig:13:  symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Cc: Bruce Allan <bruce.w.allan@intel.com>
Cc: Tadeusz Struk <tadeusz.struk@intel.com>
Cc: John Griffin <john.griffin@intel.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/crypto/qat/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/qat/Kconfig b/drivers/crypto/qat/Kconfig
index 49bede2..9bea338 100644
--- a/drivers/crypto/qat/Kconfig
+++ b/drivers/crypto/qat/Kconfig
@@ -8,7 +8,7 @@ config CRYPTO_DEV_QAT
 	select CRYPTO_SHA1
 	select CRYPTO_SHA256
 	select CRYPTO_SHA512
-	select FW_LOADER
+	depends on FW_LOADER
 
 config CRYPTO_DEV_QAT_DH895xCC
 	tristate "Support for Intel(R) DH895xCC"
-- 
2.3.2.209.gd67f9d5.dirty


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Herbert Xu]

On Tue, May 05, 2015 at 05:44:21PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> We're going to add firmware module signing support, but when we do
> this we end up with the following recursive dependency. Fix this by
> just depending on FW_LOADER, which is typically always enabled
> anyway.
> 
> mcgrof@ergon ~/linux-next (git::master)$ make allnoconfig
> scripts/kconfig/conf  --allnoconfig Kconfig
> crypto/Kconfig:15:error: recursive dependency detected!
> crypto/Kconfig:15:      symbol CRYPTO is selected by SYSDATA_SIG
> init/Kconfig:1880:      symbol SYSDATA_SIG is selected by FIRMWARE_SIG
> drivers/base/Kconfig:88:        symbol FIRMWARE_SIG depends on FW_LOADER
> drivers/base/Kconfig:80:        symbol FW_LOADER is selected by CRYPTO_DEV_QAT
> drivers/crypto/qat/Kconfig:1:   symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
> drivers/crypto/qat/Kconfig:13:  symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO

This doesn't look like a real cycle to me so perhaps we can fix
kbuild to understand this?

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Herbert Xu]

On Tue, May 05, 2015 at 05:44:21PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> We're going to add firmware module signing support, but when we do
> this we end up with the following recursive dependency. Fix this by
> just depending on FW_LOADER, which is typically always enabled
> anyway.
> 
> mcgrof@ergon ~/linux-next (git::master)$ make allnoconfig
> scripts/kconfig/conf  --allnoconfig Kconfig
> crypto/Kconfig:15:error: recursive dependency detected!
> crypto/Kconfig:15:      symbol CRYPTO is selected by SYSDATA_SIG
> init/Kconfig:1880:      symbol SYSDATA_SIG is selected by FIRMWARE_SIG
> drivers/base/Kconfig:88:        symbol FIRMWARE_SIG depends on FW_LOADER
> drivers/base/Kconfig:80:        symbol FW_LOADER is selected by CRYPTO_DEV_QAT
> drivers/crypto/qat/Kconfig:1:   symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
> drivers/crypto/qat/Kconfig:13:  symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO

This doesn't look like a real cycle to me so perhaps we can fix
kbuild to understand this?

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

On Wed, 2015-05-06 at 11:33 +0800, Herbert Xu wrote:
> On Tue, May 05, 2015 at 05:44:21PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > 
> > We're going to add firmware module signing support, but when we do
> > this we end up with the following recursive dependency. Fix this by
> > just depending on FW_LOADER, which is typically always enabled
> > anyway.
> > 
> > mcgrof@ergon ~/linux-next (git::master)$ make allnoconfig
> > scripts/kconfig/conf  --allnoconfig Kconfig
> > crypto/Kconfig:15:error: recursive dependency detected!
> > crypto/Kconfig:15:      symbol CRYPTO is selected by SYSDATA_SIG
> > init/Kconfig:1880:      symbol SYSDATA_SIG is selected by FIRMWARE_SIG
> > drivers/base/Kconfig:88:        symbol FIRMWARE_SIG depends on FW_LOADER
> > drivers/base/Kconfig:80:        symbol FW_LOADER is selected by CRYPTO_DEV_QAT
> > drivers/crypto/qat/Kconfig:1:   symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
> > drivers/crypto/qat/Kconfig:13:  symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO
> 
> This doesn't look like a real cycle to me so perhaps we can fix
> kbuild to understand this?

(Dependency circles involving selects still hurt my brain.)

Perhaps Luis should have another look at 02/12. See that patch adds this
Kconfig entry to init/Kconfig:
    config SYSDATA_SIG
	def_bool y
	select SYSTEM_TRUSTED_KEYRING
	select KEYS
	select CRYPTO
	select ASYMMETRIC_KEY_TYPE
	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
	select PUBLIC_KEY_ALGO_RSA
	select ASN1
	select OID_REGISTRY
	select X509_CERTIFICATE_PARSER

As far as I can see this is not enclosed in anything that adds any
dependencies. So that basically means that SYSDATA_SIG will always be
set, for all architectures (because I think all arches source
init/Kconfig). That should make it a pretty pointless symbol (except for
the fact that it does trigger all those selects).

The same patch also adds
	select SYSDATA_SIG

to the entry for MODULE_SIG. But to me that looks like a nop, because
SYSDATA_SIG will be set anyhow. So, but this is just I guess, the
problem might go away if
	def_bool y

is changed to just
	bool

(Note that I haven't actually tested anything here, and it wouldn't be
the first time my reasoning about Kconfig patches is completely off.)

And, whatever the value of my analysis, adding a Kconfig problem in
02/12 just to fix it in 03/12 is a bit silly. I think the patches should
be squashed if the problem can't be solved any other way.


Paul Bolle

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

On Wed, 2015-05-06 at 11:33 +0800, Herbert Xu wrote:
> On Tue, May 05, 2015 at 05:44:21PM -0700, Luis R. Rodriguez wrote:
> > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > 
> > We're going to add firmware module signing support, but when we do
> > this we end up with the following recursive dependency. Fix this by
> > just depending on FW_LOADER, which is typically always enabled
> > anyway.
> > 
> > mcgrof@ergon ~/linux-next (git::master)$ make allnoconfig
> > scripts/kconfig/conf  --allnoconfig Kconfig
> > crypto/Kconfig:15:error: recursive dependency detected!
> > crypto/Kconfig:15:      symbol CRYPTO is selected by SYSDATA_SIG
> > init/Kconfig:1880:      symbol SYSDATA_SIG is selected by FIRMWARE_SIG
> > drivers/base/Kconfig:88:        symbol FIRMWARE_SIG depends on FW_LOADER
> > drivers/base/Kconfig:80:        symbol FW_LOADER is selected by CRYPTO_DEV_QAT
> > drivers/crypto/qat/Kconfig:1:   symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
> > drivers/crypto/qat/Kconfig:13:  symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO
> 
> This doesn't look like a real cycle to me so perhaps we can fix
> kbuild to understand this?

(Dependency circles involving selects still hurt my brain.)

Perhaps Luis should have another look at 02/12. See that patch adds this
Kconfig entry to init/Kconfig:
    config SYSDATA_SIG
	def_bool y
	select SYSTEM_TRUSTED_KEYRING
	select KEYS
	select CRYPTO
	select ASYMMETRIC_KEY_TYPE
	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
	select PUBLIC_KEY_ALGO_RSA
	select ASN1
	select OID_REGISTRY
	select X509_CERTIFICATE_PARSER

As far as I can see this is not enclosed in anything that adds any
dependencies. So that basically means that SYSDATA_SIG will always be
set, for all architectures (because I think all arches source
init/Kconfig). That should make it a pretty pointless symbol (except for
the fact that it does trigger all those selects).

The same patch also adds
	select SYSDATA_SIG

to the entry for MODULE_SIG. But to me that looks like a nop, because
SYSDATA_SIG will be set anyhow. So, but this is just I guess, the
problem might go away if
	def_bool y

is changed to just
	bool

(Note that I haven't actually tested anything here, and it wouldn't be
the first time my reasoning about Kconfig patches is completely off.)

And, whatever the value of my analysis, adding a Kconfig problem in
02/12 just to fix it in 03/12 is a bit silly. I think the patches should
be squashed if the problem can't be solved any other way.


Paul Bolle


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

On Thu, 2015-05-07 at 10:42 +0200, Paul Bolle wrote:
> On Wed, 2015-05-06 at 11:33 +0800, Herbert Xu wrote:
> > On Tue, May 05, 2015 at 05:44:21PM -0700, Luis R. Rodriguez wrote:
> > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > 
> > > We're going to add firmware module signing support, but when we do
> > > this we end up with the following recursive dependency. Fix this by
> > > just depending on FW_LOADER, which is typically always enabled
> > > anyway.
> > > 
> > > mcgrof@ergon ~/linux-next (git::master)$ make allnoconfig
> > > scripts/kconfig/conf  --allnoconfig Kconfig
> > > crypto/Kconfig:15:error: recursive dependency detected!
> > > crypto/Kconfig:15:      symbol CRYPTO is selected by SYSDATA_SIG
> > > init/Kconfig:1880:      symbol SYSDATA_SIG is selected by FIRMWARE_SIG
> > > drivers/base/Kconfig:88:        symbol FIRMWARE_SIG depends on FW_LOADER
> > > drivers/base/Kconfig:80:        symbol FW_LOADER is selected by CRYPTO_DEV_QAT
> > > drivers/crypto/qat/Kconfig:1:   symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
> > > drivers/crypto/qat/Kconfig:13:  symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO
> > 
> > This doesn't look like a real cycle to me so perhaps we can fix
> > kbuild to understand this?
> 
> (Dependency circles involving selects still hurt my brain.)
> 
> Perhaps Luis should have another look at 02/12. See that patch adds this
> Kconfig entry to init/Kconfig:
>     config SYSDATA_SIG
> 	def_bool y
> 	select SYSTEM_TRUSTED_KEYRING
> 	select KEYS
> 	select CRYPTO
> 	select ASYMMETRIC_KEY_TYPE
> 	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> 	select PUBLIC_KEY_ALGO_RSA
> 	select ASN1
> 	select OID_REGISTRY
> 	select X509_CERTIFICATE_PARSER
> 
> As far as I can see this is not enclosed in anything that adds any
> dependencies. So that basically means that SYSDATA_SIG will always be
> set, for all architectures (because I think all arches source
> init/Kconfig). That should make it a pretty pointless symbol (except for
> the fact that it does trigger all those selects).
> 
> The same patch also adds
> 	select SYSDATA_SIG
> 
> to the entry for MODULE_SIG. But to me that looks like a nop, because
> SYSDATA_SIG will be set anyhow. So, but this is just I guess, the
> problem might go away if
> 	def_bool y
> 
> is changed to just
> 	bool

No, it doesn't. But the change I propose still makes sense, anyway.

> (Note that I haven't actually tested anything here, and it wouldn't be
> the first time my reasoning about Kconfig patches is completely off.)

Hear, hear!

> And, whatever the value of my analysis, adding a Kconfig problem in
> 02/12 just to fix it in 03/12 is a bit silly. I think the patches should
> be squashed if the problem can't be solved any other way.

It seems the circular dependency warning is triggered by 5/12.

And, having now fiddled a bit with this series, I think the approach
taken in this patch might actually be preferable treewide.

See, FW_LOADER is 'y' unless EXPERT is set and one goes to the trouble
of setting FW_LOADER to 'n'. So in the 100+ places where FW_LOADER is
selected, that is done for, almost always, no immediate benefit.
Changing those places to use
    depends on FW_LOADER

should have no effect, I think. Except for the EXPERT people not wanting
FW_LOADER. But that would be putting the burden where it belongs, I'd
say.

Am I missing something here?


Paul Bolle

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

On Thu, 2015-05-07 at 10:42 +0200, Paul Bolle wrote:
> On Wed, 2015-05-06 at 11:33 +0800, Herbert Xu wrote:
> > On Tue, May 05, 2015 at 05:44:21PM -0700, Luis R. Rodriguez wrote:
> > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > 
> > > We're going to add firmware module signing support, but when we do
> > > this we end up with the following recursive dependency. Fix this by
> > > just depending on FW_LOADER, which is typically always enabled
> > > anyway.
> > > 
> > > mcgrof@ergon ~/linux-next (git::master)$ make allnoconfig
> > > scripts/kconfig/conf  --allnoconfig Kconfig
> > > crypto/Kconfig:15:error: recursive dependency detected!
> > > crypto/Kconfig:15:      symbol CRYPTO is selected by SYSDATA_SIG
> > > init/Kconfig:1880:      symbol SYSDATA_SIG is selected by FIRMWARE_SIG
> > > drivers/base/Kconfig:88:        symbol FIRMWARE_SIG depends on FW_LOADER
> > > drivers/base/Kconfig:80:        symbol FW_LOADER is selected by CRYPTO_DEV_QAT
> > > drivers/crypto/qat/Kconfig:1:   symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
> > > drivers/crypto/qat/Kconfig:13:  symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO
> > 
> > This doesn't look like a real cycle to me so perhaps we can fix
> > kbuild to understand this?
> 
> (Dependency circles involving selects still hurt my brain.)
> 
> Perhaps Luis should have another look at 02/12. See that patch adds this
> Kconfig entry to init/Kconfig:
>     config SYSDATA_SIG
> 	def_bool y
> 	select SYSTEM_TRUSTED_KEYRING
> 	select KEYS
> 	select CRYPTO
> 	select ASYMMETRIC_KEY_TYPE
> 	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> 	select PUBLIC_KEY_ALGO_RSA
> 	select ASN1
> 	select OID_REGISTRY
> 	select X509_CERTIFICATE_PARSER
> 
> As far as I can see this is not enclosed in anything that adds any
> dependencies. So that basically means that SYSDATA_SIG will always be
> set, for all architectures (because I think all arches source
> init/Kconfig). That should make it a pretty pointless symbol (except for
> the fact that it does trigger all those selects).
> 
> The same patch also adds
> 	select SYSDATA_SIG
> 
> to the entry for MODULE_SIG. But to me that looks like a nop, because
> SYSDATA_SIG will be set anyhow. So, but this is just I guess, the
> problem might go away if
> 	def_bool y
> 
> is changed to just
> 	bool

No, it doesn't. But the change I propose still makes sense, anyway.

> (Note that I haven't actually tested anything here, and it wouldn't be
> the first time my reasoning about Kconfig patches is completely off.)

Hear, hear!

> And, whatever the value of my analysis, adding a Kconfig problem in
> 02/12 just to fix it in 03/12 is a bit silly. I think the patches should
> be squashed if the problem can't be solved any other way.

It seems the circular dependency warning is triggered by 5/12.

And, having now fiddled a bit with this series, I think the approach
taken in this patch might actually be preferable treewide.

See, FW_LOADER is 'y' unless EXPERT is set and one goes to the trouble
of setting FW_LOADER to 'n'. So in the 100+ places where FW_LOADER is
selected, that is done for, almost always, no immediate benefit.
Changing those places to use
    depends on FW_LOADER

should have no effect, I think. Except for the EXPERT people not wanting
FW_LOADER. But that would be putting the burden where it belongs, I'd
say.

Am I missing something here?


Paul Bolle


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Thu, May 07, 2015 at 08:06:35PM +0200, Paul Bolle wrote:
> On Thu, 2015-05-07 at 10:42 +0200, Paul Bolle wrote:
> > On Wed, 2015-05-06 at 11:33 +0800, Herbert Xu wrote:
> > > On Tue, May 05, 2015 at 05:44:21PM -0700, Luis R. Rodriguez wrote:
> > > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > > 
> > > > We're going to add firmware module signing support, but when we do
> > > > this we end up with the following recursive dependency. Fix this by
> > > > just depending on FW_LOADER, which is typically always enabled
> > > > anyway.
> > > > 
> > > > mcgrof@ergon ~/linux-next (git::master)$ make allnoconfig
> > > > scripts/kconfig/conf  --allnoconfig Kconfig
> > > > crypto/Kconfig:15:error: recursive dependency detected!
> > > > crypto/Kconfig:15:      symbol CRYPTO is selected by SYSDATA_SIG
> > > > init/Kconfig:1880:      symbol SYSDATA_SIG is selected by FIRMWARE_SIG
> > > > drivers/base/Kconfig:88:        symbol FIRMWARE_SIG depends on FW_LOADER
> > > > drivers/base/Kconfig:80:        symbol FW_LOADER is selected by CRYPTO_DEV_QAT
> > > > drivers/crypto/qat/Kconfig:1:   symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
> > > > drivers/crypto/qat/Kconfig:13:  symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO
> > > 
> > > This doesn't look like a real cycle to me so perhaps we can fix
> > > kbuild to understand this?
> > 
> > (Dependency circles involving selects still hurt my brain.)
> > 
> > Perhaps Luis should have another look at 02/12. See that patch adds this
> > Kconfig entry to init/Kconfig:
> >     config SYSDATA_SIG
> > 	def_bool y
> > 	select SYSTEM_TRUSTED_KEYRING
> > 	select KEYS
> > 	select CRYPTO
> > 	select ASYMMETRIC_KEY_TYPE
> > 	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> > 	select PUBLIC_KEY_ALGO_RSA
> > 	select ASN1
> > 	select OID_REGISTRY
> > 	select X509_CERTIFICATE_PARSER
> > 
> > As far as I can see this is not enclosed in anything that adds any
> > dependencies. So that basically means that SYSDATA_SIG will always be
> > set, for all architectures (because I think all arches source
> > init/Kconfig). That should make it a pretty pointless symbol (except for
> > the fact that it does trigger all those selects).
> > 
> > The same patch also adds
> > 	select SYSDATA_SIG
> > 
> > to the entry for MODULE_SIG. But to me that looks like a nop, because
> > SYSDATA_SIG will be set anyhow. So, but this is just I guess, the
> > problem might go away if
> > 	def_bool y
> > 
> > is changed to just
> > 	bool
> 
> No, it doesn't. But the change I propose still makes sense, anyway.

Thanks, yeah that should be fixed to def_bool n. I had tried def_bool n
before my submission and that didn't fix it, for some reason I forgot to
ammend that change.

> > (Note that I haven't actually tested anything here, and it wouldn't be
> > the first time my reasoning about Kconfig patches is completely off.)
> 
> Hear, hear!
> 
> > And, whatever the value of my analysis, adding a Kconfig problem in
> > 02/12 just to fix it in 03/12 is a bit silly. I think the patches should
> > be squashed if the problem can't be solved any other way.
> 
> It seems the circular dependency warning is triggered by 5/12.
> 
> And, having now fiddled a bit with this series, I think the approach
> taken in this patch might actually be preferable treewide.
> 
> See, FW_LOADER is 'y' unless EXPERT is set and one goes to the trouble
> of setting FW_LOADER to 'n'. So in the 100+ places where FW_LOADER is
> selected, that is done for, almost always, no immediate benefit.
> Changing those places to use
>     depends on FW_LOADER
> 
> should have no effect, I think. Except for the EXPERT people not wanting
> FW_LOADER. But that would be putting the burden where it belongs, I'd
> say.

I think this is a correct assessment but only because FW_LOADER is
exposed as optional via EXPERT mode. We can go on a cursade for that
if folks are OK with that.

> Am I missing something here?

Yeah, I think this issue is deeper and *must* be fixed as otherwise
we can't later do more complex intersection dependencies. What we
do *for now* -- perhaps my patch is OK then given your assessemnt,
but for our TODO item, we must keep track that we need to fix this.

Let me explain.

Based on a closer look at the qat Kconfig file I think the issue
might be that for some reason kbuild is assuming that a symbol's
select's and their own dependencies are in and of themselves
related dependencies, that is incorrect. Although the request_firmware()
call is done within the common code (CRYPTO_DEV_QAT), if just for
testing purposes of my point we move "select FW_LOADER" to
CRYPTO_DEV_QAT_DH895xCC the dependency issue becomes clearer:

mcgrof@ergon ~/linux-next (git::your-recursive-qat-mom)$ make allnoconfig
scripts/kconfig/conf  --allnoconfig Kconfig
crypto/Kconfig:15:error: recursive dependency detected!
crypto/Kconfig:15:	symbol CRYPTO is selected by SYSDATA_SIG
init/Kconfig:1880:	symbol SYSDATA_SIG is selected by FIRMWARE_SIG
drivers/base/Kconfig:88:	symbol FIRMWARE_SIG depends on FW_LOADER
drivers/base/Kconfig:80:	symbol FW_LOADER is selected by CRYPTO_DEV_QAT_DH895xCC
drivers/crypto/qat/Kconfig:12:	symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO
#
# configuration written to .config
#

I'm saying that *if* the request_firmware() call was in
CRYPTO_DEV_QAT_DH895xCC it would be wrong for kbuild to think
that CRYPTO is somehow a dependency for FW_LOADER, although
the above does not say that I think I thinks that as otherwise
I cannot see why this would be considered a recursive dependency.

This issue can be made clear by just removing as a test
CRYPTO_DEV_QAT all together and having CRYPTO_DEV_QAT_DH895xCC
select CRYPTO:

config CRYPTO_DEV_QAT_DH895xCC                                                  
        tristate "Support for Intel(R) DH895xCC"                                
        depends on X86 && PCI                                                   
        default n                                                               
        select CRYPTO                                                           
        select FW_LOADER                                                        
        help                                                                    
          Support for Intel(R) DH895xcc with Intel(R) QuickAssist Technology    
          for accelerating crypto and compression workloads.                    
                                                                                
          To compile this as a module, choose M here: the module                
          will be called qat_dh895xcc. 

mcgrof@ergon ~/linux-next (git::your-recursive-qat-mom)$ make allnoconfig
scripts/kconfig/conf  --allnoconfig Kconfig
crypto/Kconfig:15:error: recursive dependency detected!
crypto/Kconfig:15:	symbol CRYPTO is selected by SYSDATA_SIG
init/Kconfig:1880:	symbol SYSDATA_SIG is selected by FIRMWARE_SIG
drivers/base/Kconfig:88:	symbol FIRMWARE_SIG depends on FW_LOADER
drivers/base/Kconfig:80:	symbol FW_LOADER is selected by CRYPTO_DEV_QAT_DH895xCC
drivers/crypto/qat/Kconfig:1:	symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO
#
# configuration written to .config
#

So it should not mean that if CRYPTO_DEV_QAT_DH895xCC's selects something
that that select depends on other of CRYPTO_DEV_QAT_DH895xCC's
selects. For instance in this case it would would mean that we
could not negate a feature that other drivers that selected FW_LOADER
enabled.

Here's a simple test Kconfig entry one can use to test this:

Let's say rock climbers hate locker rooms, but swimmer need them. We can
then have:

config GYM                                                                      
        tristate                                                                
        default n                                                               
                                                                                
config LOCKER                                                                   
        tristate                                                                
        default n                                                               
        depends on GYM                                                          
                                                                                
config SWIMMING                                                                 
        tristate                                                                
        default n                                                               
        select GYM                                                              
        select LOCKER                                                           
                                                                                
config ROCK_CLIMBING                                                            
        tristate                                                                
        default n                                                               
        depends on !LOCKER                                                      
        select GYM  

Kbuild seems to believe that because swimmers need lockers that rock climbers
need them too. That is obviously not true.

mcgrof@ergon ~/linux-next (git::your-swimming-dad)$ make allnoconfig
scripts/kconfig/conf --allnoconfig Kconfig
drivers/crypto/qat/Kconfig:25:error: recursive dependency detected!
drivers/crypto/qat/Kconfig:25:	symbol GYM is selected by ROCK_CLIMBING
drivers/crypto/qat/Kconfig:40:	symbol ROCK_CLIMBING depends on LOCKER
drivers/crypto/qat/Kconfig:29:	symbol LOCKER depends on GYM
#
# configuration written to .config
#

So kbuild does not accept intersection of a feature as a possible outlet
for a dependency, it wants things very atomic. In the FW_SIG case we do
want to enable FW_LOADER but not have all drivers require CRYPTO. The
issue is created because kbuild thinks FW_LOADER depends on CRYPTO
given that a driver selects it.

  Luis

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Thu, May 07, 2015 at 08:06:35PM +0200, Paul Bolle wrote:
> On Thu, 2015-05-07 at 10:42 +0200, Paul Bolle wrote:
> > On Wed, 2015-05-06 at 11:33 +0800, Herbert Xu wrote:
> > > On Tue, May 05, 2015 at 05:44:21PM -0700, Luis R. Rodriguez wrote:
> > > > From: "Luis R. Rodriguez" <mcgrof@suse.com>
> > > > 
> > > > We're going to add firmware module signing support, but when we do
> > > > this we end up with the following recursive dependency. Fix this by
> > > > just depending on FW_LOADER, which is typically always enabled
> > > > anyway.
> > > > 
> > > > mcgrof@ergon ~/linux-next (git::master)$ make allnoconfig
> > > > scripts/kconfig/conf  --allnoconfig Kconfig
> > > > crypto/Kconfig:15:error: recursive dependency detected!
> > > > crypto/Kconfig:15:      symbol CRYPTO is selected by SYSDATA_SIG
> > > > init/Kconfig:1880:      symbol SYSDATA_SIG is selected by FIRMWARE_SIG
> > > > drivers/base/Kconfig:88:        symbol FIRMWARE_SIG depends on FW_LOADER
> > > > drivers/base/Kconfig:80:        symbol FW_LOADER is selected by CRYPTO_DEV_QAT
> > > > drivers/crypto/qat/Kconfig:1:   symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
> > > > drivers/crypto/qat/Kconfig:13:  symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO
> > > 
> > > This doesn't look like a real cycle to me so perhaps we can fix
> > > kbuild to understand this?
> > 
> > (Dependency circles involving selects still hurt my brain.)
> > 
> > Perhaps Luis should have another look at 02/12. See that patch adds this
> > Kconfig entry to init/Kconfig:
> >     config SYSDATA_SIG
> > 	def_bool y
> > 	select SYSTEM_TRUSTED_KEYRING
> > 	select KEYS
> > 	select CRYPTO
> > 	select ASYMMETRIC_KEY_TYPE
> > 	select ASYMMETRIC_PUBLIC_KEY_SUBTYPE
> > 	select PUBLIC_KEY_ALGO_RSA
> > 	select ASN1
> > 	select OID_REGISTRY
> > 	select X509_CERTIFICATE_PARSER
> > 
> > As far as I can see this is not enclosed in anything that adds any
> > dependencies. So that basically means that SYSDATA_SIG will always be
> > set, for all architectures (because I think all arches source
> > init/Kconfig). That should make it a pretty pointless symbol (except for
> > the fact that it does trigger all those selects).
> > 
> > The same patch also adds
> > 	select SYSDATA_SIG
> > 
> > to the entry for MODULE_SIG. But to me that looks like a nop, because
> > SYSDATA_SIG will be set anyhow. So, but this is just I guess, the
> > problem might go away if
> > 	def_bool y
> > 
> > is changed to just
> > 	bool
> 
> No, it doesn't. But the change I propose still makes sense, anyway.

Thanks, yeah that should be fixed to def_bool n. I had tried def_bool n
before my submission and that didn't fix it, for some reason I forgot to
ammend that change.

> > (Note that I haven't actually tested anything here, and it wouldn't be
> > the first time my reasoning about Kconfig patches is completely off.)
> 
> Hear, hear!
> 
> > And, whatever the value of my analysis, adding a Kconfig problem in
> > 02/12 just to fix it in 03/12 is a bit silly. I think the patches should
> > be squashed if the problem can't be solved any other way.
> 
> It seems the circular dependency warning is triggered by 5/12.
> 
> And, having now fiddled a bit with this series, I think the approach
> taken in this patch might actually be preferable treewide.
> 
> See, FW_LOADER is 'y' unless EXPERT is set and one goes to the trouble
> of setting FW_LOADER to 'n'. So in the 100+ places where FW_LOADER is
> selected, that is done for, almost always, no immediate benefit.
> Changing those places to use
>     depends on FW_LOADER
> 
> should have no effect, I think. Except for the EXPERT people not wanting
> FW_LOADER. But that would be putting the burden where it belongs, I'd
> say.

I think this is a correct assessment but only because FW_LOADER is
exposed as optional via EXPERT mode. We can go on a cursade for that
if folks are OK with that.

> Am I missing something here?

Yeah, I think this issue is deeper and *must* be fixed as otherwise
we can't later do more complex intersection dependencies. What we
do *for now* -- perhaps my patch is OK then given your assessemnt,
but for our TODO item, we must keep track that we need to fix this.

Let me explain.

Based on a closer look at the qat Kconfig file I think the issue
might be that for some reason kbuild is assuming that a symbol's
select's and their own dependencies are in and of themselves
related dependencies, that is incorrect. Although the request_firmware()
call is done within the common code (CRYPTO_DEV_QAT), if just for
testing purposes of my point we move "select FW_LOADER" to
CRYPTO_DEV_QAT_DH895xCC the dependency issue becomes clearer:

mcgrof@ergon ~/linux-next (git::your-recursive-qat-mom)$ make allnoconfig
scripts/kconfig/conf  --allnoconfig Kconfig
crypto/Kconfig:15:error: recursive dependency detected!
crypto/Kconfig:15:	symbol CRYPTO is selected by SYSDATA_SIG
init/Kconfig:1880:	symbol SYSDATA_SIG is selected by FIRMWARE_SIG
drivers/base/Kconfig:88:	symbol FIRMWARE_SIG depends on FW_LOADER
drivers/base/Kconfig:80:	symbol FW_LOADER is selected by CRYPTO_DEV_QAT_DH895xCC
drivers/crypto/qat/Kconfig:12:	symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO
#
# configuration written to .config
#

I'm saying that *if* the request_firmware() call was in
CRYPTO_DEV_QAT_DH895xCC it would be wrong for kbuild to think
that CRYPTO is somehow a dependency for FW_LOADER, although
the above does not say that I think I thinks that as otherwise
I cannot see why this would be considered a recursive dependency.

This issue can be made clear by just removing as a test
CRYPTO_DEV_QAT all together and having CRYPTO_DEV_QAT_DH895xCC
select CRYPTO:

config CRYPTO_DEV_QAT_DH895xCC                                                  
        tristate "Support for Intel(R) DH895xCC"                                
        depends on X86 && PCI                                                   
        default n                                                               
        select CRYPTO                                                           
        select FW_LOADER                                                        
        help                                                                    
          Support for Intel(R) DH895xcc with Intel(R) QuickAssist Technology    
          for accelerating crypto and compression workloads.                    
                                                                                
          To compile this as a module, choose M here: the module                
          will be called qat_dh895xcc. 

mcgrof@ergon ~/linux-next (git::your-recursive-qat-mom)$ make allnoconfig
scripts/kconfig/conf  --allnoconfig Kconfig
crypto/Kconfig:15:error: recursive dependency detected!
crypto/Kconfig:15:	symbol CRYPTO is selected by SYSDATA_SIG
init/Kconfig:1880:	symbol SYSDATA_SIG is selected by FIRMWARE_SIG
drivers/base/Kconfig:88:	symbol FIRMWARE_SIG depends on FW_LOADER
drivers/base/Kconfig:80:	symbol FW_LOADER is selected by CRYPTO_DEV_QAT_DH895xCC
drivers/crypto/qat/Kconfig:1:	symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO
#
# configuration written to .config
#

So it should not mean that if CRYPTO_DEV_QAT_DH895xCC's selects something
that that select depends on other of CRYPTO_DEV_QAT_DH895xCC's
selects. For instance in this case it would would mean that we
could not negate a feature that other drivers that selected FW_LOADER
enabled.

Here's a simple test Kconfig entry one can use to test this:

Let's say rock climbers hate locker rooms, but swimmer need them. We can
then have:

config GYM                                                                      
        tristate                                                                
        default n                                                               
                                                                                
config LOCKER                                                                   
        tristate                                                                
        default n                                                               
        depends on GYM                                                          
                                                                                
config SWIMMING                                                                 
        tristate                                                                
        default n                                                               
        select GYM                                                              
        select LOCKER                                                           
                                                                                
config ROCK_CLIMBING                                                            
        tristate                                                                
        default n                                                               
        depends on !LOCKER                                                      
        select GYM  

Kbuild seems to believe that because swimmers need lockers that rock climbers
need them too. That is obviously not true.

mcgrof@ergon ~/linux-next (git::your-swimming-dad)$ make allnoconfig
scripts/kconfig/conf --allnoconfig Kconfig
drivers/crypto/qat/Kconfig:25:error: recursive dependency detected!
drivers/crypto/qat/Kconfig:25:	symbol GYM is selected by ROCK_CLIMBING
drivers/crypto/qat/Kconfig:40:	symbol ROCK_CLIMBING depends on LOCKER
drivers/crypto/qat/Kconfig:29:	symbol LOCKER depends on GYM
#
# configuration written to .config
#

So kbuild does not accept intersection of a feature as a possible outlet
for a dependency, it wants things very atomic. In the FW_SIG case we do
want to enable FW_LOADER but not have all drivers require CRYPTO. The
issue is created because kbuild thinks FW_LOADER depends on CRYPTO
given that a driver selects it.

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

On Thu, 2015-05-07 at 20:28 +0200, Luis R. Rodriguez wrote:
> Here's a simple test Kconfig entry one can use to test this:
> 
> Let's say rock climbers hate locker rooms, but swimmer need them. We can
> then have:
> 
> config GYM                                                                      
>         tristate                                                                
>         default n                                                               
>                                                                                 
> config LOCKER                                                                   
>         tristate                                                                
>         default n                                                               
>         depends on GYM                                                          
>                                                                                 
> config SWIMMING                                                                 
>         tristate                                                                
>         default n                                                               
>         select GYM                                                              
>         select LOCKER                                                           
>                                                                                 
> config ROCK_CLIMBING                                                            
>         tristate                                                                
>         default n                                                               
>         depends on !LOCKER                                                      
>         select GYM  
> 
> Kbuild seems to believe that because swimmers need lockers that rock climbers
> need them too. That is obviously not true.
> 
> mcgrof@ergon ~/linux-next (git::your-swimming-dad)$ make allnoconfig
> scripts/kconfig/conf --allnoconfig Kconfig
> drivers/crypto/qat/Kconfig:25:error: recursive dependency detected!
> drivers/crypto/qat/Kconfig:25:	symbol GYM is selected by ROCK_CLIMBING
> drivers/crypto/qat/Kconfig:40:	symbol ROCK_CLIMBING depends on LOCKER
> drivers/crypto/qat/Kconfig:29:	symbol LOCKER depends on GYM
> #
> # configuration written to .config
> #

The same error can be seen with this Kconfig file (simplified in some
places):

# test with 'make KBUILD_KCONFIG=Kconfig.your-swimming-dad menuconfig'
mainmenu "Your swimming dad"

config MODULES
	def_bool y
	option modules

config GYM
        tristate "Gym"

config LOCKER
        tristate "Locker"
	depends on GYM

config ROCK_CLIMBING
        tristate "Rock climbing"
	depends on LOCKER
	select GYM

But then I think it's helpful to also play with this very similar file:

# test with 'make KBUILD_KCONFIG=Kconfig.your-swimming-mom menuconfig'
mainmenu "Your swimming mom"

config MODULES
	def_bool y
	option modules

config GYM
        tristate "Gym"
	depends on ROCK_CLIMBING

config LOCKER
        tristate "Locker"
	depends on GYM

config ROCK_CLIMBING
        tristate "Rock climbing"
	depends on LOCKER

This triggers the same error but with this as first line:
    symbol GYM depends on ROCK_CLIMBING

Now the circular dependency in mom's Kconfig file is rather obvious. The
circular dependency in dad's file too, once you adapt to the reverse
logic of select statements. (The part that makes my brain hurt.)

Tomorrow, after a (western European) night of sleep, I hope to explain
why the error in dad's file makes sense. I'm not much of a teacher so I
need a clear head to do that.

Thanks,


Paul Bolle

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

On Thu, 2015-05-07 at 20:28 +0200, Luis R. Rodriguez wrote:
> Here's a simple test Kconfig entry one can use to test this:
> 
> Let's say rock climbers hate locker rooms, but swimmer need them. We can
> then have:
> 
> config GYM                                                                      
>         tristate                                                                
>         default n                                                               
>                                                                                 
> config LOCKER                                                                   
>         tristate                                                                
>         default n                                                               
>         depends on GYM                                                          
>                                                                                 
> config SWIMMING                                                                 
>         tristate                                                                
>         default n                                                               
>         select GYM                                                              
>         select LOCKER                                                           
>                                                                                 
> config ROCK_CLIMBING                                                            
>         tristate                                                                
>         default n                                                               
>         depends on !LOCKER                                                      
>         select GYM  
> 
> Kbuild seems to believe that because swimmers need lockers that rock climbers
> need them too. That is obviously not true.
> 
> mcgrof@ergon ~/linux-next (git::your-swimming-dad)$ make allnoconfig
> scripts/kconfig/conf --allnoconfig Kconfig
> drivers/crypto/qat/Kconfig:25:error: recursive dependency detected!
> drivers/crypto/qat/Kconfig:25:	symbol GYM is selected by ROCK_CLIMBING
> drivers/crypto/qat/Kconfig:40:	symbol ROCK_CLIMBING depends on LOCKER
> drivers/crypto/qat/Kconfig:29:	symbol LOCKER depends on GYM
> #
> # configuration written to .config
> #

The same error can be seen with this Kconfig file (simplified in some
places):

# test with 'make KBUILD_KCONFIG=Kconfig.your-swimming-dad menuconfig'
mainmenu "Your swimming dad"

config MODULES
	def_bool y
	option modules

config GYM
        tristate "Gym"

config LOCKER
        tristate "Locker"
	depends on GYM

config ROCK_CLIMBING
        tristate "Rock climbing"
	depends on LOCKER
	select GYM

But then I think it's helpful to also play with this very similar file:

# test with 'make KBUILD_KCONFIG=Kconfig.your-swimming-mom menuconfig'
mainmenu "Your swimming mom"

config MODULES
	def_bool y
	option modules

config GYM
        tristate "Gym"
	depends on ROCK_CLIMBING

config LOCKER
        tristate "Locker"
	depends on GYM

config ROCK_CLIMBING
        tristate "Rock climbing"
	depends on LOCKER

This triggers the same error but with this as first line:
    symbol GYM depends on ROCK_CLIMBING

Now the circular dependency in mom's Kconfig file is rather obvious. The
circular dependency in dad's file too, once you adapt to the reverse
logic of select statements. (The part that makes my brain hurt.)

Tomorrow, after a (western European) night of sleep, I hope to explain
why the error in dad's file makes sense. I'm not much of a teacher so I
need a clear head to do that.

Thanks,


Paul Bolle


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

On Thu, 2015-05-07 at 22:14 +0200, Paul Bolle wrote:
> Tomorrow, after a (western European) night of sleep, I hope to explain
> why the error in dad's file makes sense. I'm not much of a teacher so I
> need a clear head to do that.

Let's start with mom's Kconfig file. It triggers
	error: recursive dependency detected!
	symbol GYM depends on ROCK_CLIMBING
	symbol ROCK_CLIMBING depends on LOCKER
	symbol LOCKER depends on GYM

Now you should realize that the kconfig tools have to answers questions
like these, for each (tristate) symbol:
	- must it be 'n'; or
	- can it be 'm'; or
	- can it be 'y'.

Take, for example: can GYM be 'y'? Since GYM depends on ROCK_CLIMBING,
it can only be 'y' if ROCK_CLIMBING is 'y' (both being tristate). And
ROCK_CLIMBING depends on LOCKER, so ROCK_CLIMBING can only be 'y' if
LOCKER is 'y' (ditto). And LOCKER, in its turn, depends on GYM, so it
can only be 'y', if GYM is 'y'.

But we can't say whether GYM is 'y' yet, as it can still be 'n', 'm', or
'y' for all we know. So we can't answer that question. Hence the
recursive dependency error. (There must be a term for this obvious
problem in formal logic, but I'm not trained in formal logic.)

On to dad's Kconfig file (which is your example, but simplified). That
triggers:
	error: recursive dependency detected!
	symbol GYM is selected by ROCK_CLIMBING
	symbol ROCK_CLIMBING depends on LOCKER
	symbol LOCKER depends on GYM

Let's try to determine whether GYM should be 'n'. Well, GYM is selected
by ROCK_CLIMBING so it cannot be 'n' if ROCK_CLIMBING is 'm' or 'y'. (If
ROCK_CLIMBING is 'm' it can be 'm' or 'y', but not 'n', and if
ROCK_CLIMBING is 'y' it must be 'y'.) Do we know whether ROCK_CLIMBING
should be 'n'? It should be 'n' only if LOCKER is 'n'. And LOCKER should
in its turn be 'n' if GYM is 'n'. But we don't know yet what GYM will
be. So, again, we can't answer this question. Recursive dependency
error!

The complicated error you ran into was
	error: recursive dependency detected!
	symbol CRYPTO is selected by SYSDATA_SIG
	symbol SYSDATA_SIG is selected by FIRMWARE_SIG
	symbol FIRMWARE_SIG depends on FW_LOADER
	symbol FW_LOADER is selected by CRYPTO_DEV_QAT
	symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
	symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO

I'm lazy, so I haven't gone through this error step by step. But I'm
sure it's just a complicated version of what I tried to explain in the
above two examples. But if you're unconvinced I'll try to go through
this error too.

Now I'm sure the point I'm trying to make can be made more convincingly
and more elegantly. But the thing is, I think, that given how "select"
works and how "depends on" works, some setups will trigger these errors.
One might wish that "select" or "depends on" behaved differently, but
with the thousands of Kconfig symbols now in use, that really looks
unfeasible.

(Now let's see how all the, mostly German, people trained in formal
logic that appear to care about the kconfig tools shoot holes in my
reasoning.)

Hope this helps,


Paul Bolle

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

On Thu, 2015-05-07 at 22:14 +0200, Paul Bolle wrote:
> Tomorrow, after a (western European) night of sleep, I hope to explain
> why the error in dad's file makes sense. I'm not much of a teacher so I
> need a clear head to do that.

Let's start with mom's Kconfig file. It triggers
	error: recursive dependency detected!
	symbol GYM depends on ROCK_CLIMBING
	symbol ROCK_CLIMBING depends on LOCKER
	symbol LOCKER depends on GYM

Now you should realize that the kconfig tools have to answers questions
like these, for each (tristate) symbol:
	- must it be 'n'; or
	- can it be 'm'; or
	- can it be 'y'.

Take, for example: can GYM be 'y'? Since GYM depends on ROCK_CLIMBING,
it can only be 'y' if ROCK_CLIMBING is 'y' (both being tristate). And
ROCK_CLIMBING depends on LOCKER, so ROCK_CLIMBING can only be 'y' if
LOCKER is 'y' (ditto). And LOCKER, in its turn, depends on GYM, so it
can only be 'y', if GYM is 'y'.

But we can't say whether GYM is 'y' yet, as it can still be 'n', 'm', or
'y' for all we know. So we can't answer that question. Hence the
recursive dependency error. (There must be a term for this obvious
problem in formal logic, but I'm not trained in formal logic.)

On to dad's Kconfig file (which is your example, but simplified). That
triggers:
	error: recursive dependency detected!
	symbol GYM is selected by ROCK_CLIMBING
	symbol ROCK_CLIMBING depends on LOCKER
	symbol LOCKER depends on GYM

Let's try to determine whether GYM should be 'n'. Well, GYM is selected
by ROCK_CLIMBING so it cannot be 'n' if ROCK_CLIMBING is 'm' or 'y'. (If
ROCK_CLIMBING is 'm' it can be 'm' or 'y', but not 'n', and if
ROCK_CLIMBING is 'y' it must be 'y'.) Do we know whether ROCK_CLIMBING
should be 'n'? It should be 'n' only if LOCKER is 'n'. And LOCKER should
in its turn be 'n' if GYM is 'n'. But we don't know yet what GYM will
be. So, again, we can't answer this question. Recursive dependency
error!

The complicated error you ran into was
	error: recursive dependency detected!
	symbol CRYPTO is selected by SYSDATA_SIG
	symbol SYSDATA_SIG is selected by FIRMWARE_SIG
	symbol FIRMWARE_SIG depends on FW_LOADER
	symbol FW_LOADER is selected by CRYPTO_DEV_QAT
	symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
	symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO

I'm lazy, so I haven't gone through this error step by step. But I'm
sure it's just a complicated version of what I tried to explain in the
above two examples. But if you're unconvinced I'll try to go through
this error too.

Now I'm sure the point I'm trying to make can be made more convincingly
and more elegantly. But the thing is, I think, that given how "select"
works and how "depends on" works, some setups will trigger these errors.
One might wish that "select" or "depends on" behaved differently, but
with the thousands of Kconfig symbols now in use, that really looks
unfeasible.

(Now let's see how all the, mostly German, people trained in formal
logic that appear to care about the kconfig tools shoot holes in my
reasoning.)

Hope this helps,


Paul Bolle


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Fri, May 08, 2015 at 11:53:03PM +0200, Paul Bolle wrote:
> On Thu, 2015-05-07 at 22:14 +0200, Paul Bolle wrote:
> > Tomorrow, after a (western European) night of sleep, I hope to explain
> > why the error in dad's file makes sense. I'm not much of a teacher so I
> > need a clear head to do that.
> 
> Let's start with mom's Kconfig file. It triggers
> 	error: recursive dependency detected!
> 	symbol GYM depends on ROCK_CLIMBING
> 	symbol ROCK_CLIMBING depends on LOCKER
> 	symbol LOCKER depends on GYM
> 
> Now you should realize that the kconfig tools have to answers questions
> like these, for each (tristate) symbol:
> 	- must it be 'n'; or
> 	- can it be 'm'; or
> 	- can it be 'y'.
> 
> Take, for example: can GYM be 'y'? Since GYM depends on ROCK_CLIMBING,
> it can only be 'y' if ROCK_CLIMBING is 'y' (both being tristate). And
> ROCK_CLIMBING depends on LOCKER, so ROCK_CLIMBING can only be 'y' if
> LOCKER is 'y' (ditto). And LOCKER, in its turn, depends on GYM, so it
> can only be 'y', if GYM is 'y'.
> 
> But we can't say whether GYM is 'y' yet, as it can still be 'n', 'm', or
> 'y' for all we know. So we can't answer that question. Hence the
> recursive dependency error. (There must be a term for this obvious
> problem in formal logic, but I'm not trained in formal logic.)
> 
> On to dad's Kconfig file (which is your example, but simplified). That
> triggers:
> 	error: recursive dependency detected!
> 	symbol GYM is selected by ROCK_CLIMBING
> 	symbol ROCK_CLIMBING depends on LOCKER
> 	symbol LOCKER depends on GYM

Note, I had ROCK_CLIMBING depeneds on !LOCKER, but indeed LOCKER does
depend on GYM.

> Let's try to determine whether GYM should be 'n'. Well, GYM is selected
> by ROCK_CLIMBING so it cannot be 'n' if ROCK_CLIMBING is 'm' or 'y'. (If
> ROCK_CLIMBING is 'm' it can be 'm' or 'y', but not 'n', and if
> ROCK_CLIMBING is 'y' it must be 'y'.) Do we know whether ROCK_CLIMBING
> should be 'n'? It should be 'n' only if LOCKER is 'n'. And LOCKER should
> in its turn be 'n' if GYM is 'n'. But we don't know yet what GYM will
> be. So, again, we can't answer this question. Recursive dependency
> error!

True, whether or not it was "depend on LOCKER" or "depends on !LOCKER"
in order to answer the negative question of whether GYM should be 'n'
indeed we reach a recursive dependency because of the indirect
link between rock climbing and gym through a depends which does have
a direct dependency. The issue here though is we want a "select" to
do work for us, we don't want it to resolve all the logic's possible
questions yet. The select is saying enable GYM now, and it should do
that now (in your case above) if LOCKER is enabled. Now, since LOCKER
does depend on GYM though it should mean that what items were selected
were dependencies of LOCKER we should go ahead and also enable those,
in this case it is GYM but we know we want that enabled, so we can
enable both now.

In light of what you described then I wonder if we do not need to
ask certain questions on the kbuild logic when select is used, or
if we need a whitelist?

> The complicated error you ran into was
> 	error: recursive dependency detected!
> 	symbol CRYPTO is selected by SYSDATA_SIG
> 	symbol SYSDATA_SIG is selected by FIRMWARE_SIG
> 	symbol FIRMWARE_SIG depends on FW_LOADER
> 	symbol FW_LOADER is selected by CRYPTO_DEV_QAT
> 	symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
> 	symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO
> 
> I'm lazy, so I haven't gone through this error step by step. But I'm
> sure it's just a complicated version of what I tried to explain in the
> above two examples. But if you're unconvinced I'll try to go through
> this error too.

No thanks, you've done an awesome job in explaining why it is proper and
recursive given the above two examples by considering the requirements that
kconfig has to address.

> Now I'm sure the point I'm trying to make can be made more convincingly
> and more elegantly. But the thing is, I think, that given how "select"
> works and how "depends on" works, some setups will trigger these errors.
> One might wish that "select" or "depends on" behaved differently, but
> with the thousands of Kconfig symbols now in use, that really looks
> unfeasible.

Yeah I am not sure if a fix is as simple as I described.

In the meantime I'll go ahead with the original patch but change the
wording given that FW_LOADEr is EXPERT and this is still being discussed.

  Luis

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Fri, May 08, 2015 at 11:53:03PM +0200, Paul Bolle wrote:
> On Thu, 2015-05-07 at 22:14 +0200, Paul Bolle wrote:
> > Tomorrow, after a (western European) night of sleep, I hope to explain
> > why the error in dad's file makes sense. I'm not much of a teacher so I
> > need a clear head to do that.
> 
> Let's start with mom's Kconfig file. It triggers
> 	error: recursive dependency detected!
> 	symbol GYM depends on ROCK_CLIMBING
> 	symbol ROCK_CLIMBING depends on LOCKER
> 	symbol LOCKER depends on GYM
> 
> Now you should realize that the kconfig tools have to answers questions
> like these, for each (tristate) symbol:
> 	- must it be 'n'; or
> 	- can it be 'm'; or
> 	- can it be 'y'.
> 
> Take, for example: can GYM be 'y'? Since GYM depends on ROCK_CLIMBING,
> it can only be 'y' if ROCK_CLIMBING is 'y' (both being tristate). And
> ROCK_CLIMBING depends on LOCKER, so ROCK_CLIMBING can only be 'y' if
> LOCKER is 'y' (ditto). And LOCKER, in its turn, depends on GYM, so it
> can only be 'y', if GYM is 'y'.
> 
> But we can't say whether GYM is 'y' yet, as it can still be 'n', 'm', or
> 'y' for all we know. So we can't answer that question. Hence the
> recursive dependency error. (There must be a term for this obvious
> problem in formal logic, but I'm not trained in formal logic.)
> 
> On to dad's Kconfig file (which is your example, but simplified). That
> triggers:
> 	error: recursive dependency detected!
> 	symbol GYM is selected by ROCK_CLIMBING
> 	symbol ROCK_CLIMBING depends on LOCKER
> 	symbol LOCKER depends on GYM

Note, I had ROCK_CLIMBING depeneds on !LOCKER, but indeed LOCKER does
depend on GYM.

> Let's try to determine whether GYM should be 'n'. Well, GYM is selected
> by ROCK_CLIMBING so it cannot be 'n' if ROCK_CLIMBING is 'm' or 'y'. (If
> ROCK_CLIMBING is 'm' it can be 'm' or 'y', but not 'n', and if
> ROCK_CLIMBING is 'y' it must be 'y'.) Do we know whether ROCK_CLIMBING
> should be 'n'? It should be 'n' only if LOCKER is 'n'. And LOCKER should
> in its turn be 'n' if GYM is 'n'. But we don't know yet what GYM will
> be. So, again, we can't answer this question. Recursive dependency
> error!

True, whether or not it was "depend on LOCKER" or "depends on !LOCKER"
in order to answer the negative question of whether GYM should be 'n'
indeed we reach a recursive dependency because of the indirect
link between rock climbing and gym through a depends which does have
a direct dependency. The issue here though is we want a "select" to
do work for us, we don't want it to resolve all the logic's possible
questions yet. The select is saying enable GYM now, and it should do
that now (in your case above) if LOCKER is enabled. Now, since LOCKER
does depend on GYM though it should mean that what items were selected
were dependencies of LOCKER we should go ahead and also enable those,
in this case it is GYM but we know we want that enabled, so we can
enable both now.

In light of what you described then I wonder if we do not need to
ask certain questions on the kbuild logic when select is used, or
if we need a whitelist?

> The complicated error you ran into was
> 	error: recursive dependency detected!
> 	symbol CRYPTO is selected by SYSDATA_SIG
> 	symbol SYSDATA_SIG is selected by FIRMWARE_SIG
> 	symbol FIRMWARE_SIG depends on FW_LOADER
> 	symbol FW_LOADER is selected by CRYPTO_DEV_QAT
> 	symbol CRYPTO_DEV_QAT is selected by CRYPTO_DEV_QAT_DH895xCC
> 	symbol CRYPTO_DEV_QAT_DH895xCC depends on CRYPTO
> 
> I'm lazy, so I haven't gone through this error step by step. But I'm
> sure it's just a complicated version of what I tried to explain in the
> above two examples. But if you're unconvinced I'll try to go through
> this error too.

No thanks, you've done an awesome job in explaining why it is proper and
recursive given the above two examples by considering the requirements that
kconfig has to address.

> Now I'm sure the point I'm trying to make can be made more convincingly
> and more elegantly. But the thing is, I think, that given how "select"
> works and how "depends on" works, some setups will trigger these errors.
> One might wish that "select" or "depends on" behaved differently, but
> with the thousands of Kconfig symbols now in use, that really looks
> unfeasible.

Yeah I am not sure if a fix is as simple as I described.

In the meantime I'll go ahead with the original patch but change the
wording given that FW_LOADEr is EXPERT and this is still being discussed.

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Thu, May 07, 2015 at 08:06:35PM +0200, Paul Bolle wrote:
> See, FW_LOADER is 'y' unless EXPERT is set and one goes to the trouble
> of setting FW_LOADER to 'n'. So in the 100+ places where FW_LOADER is
> selected, that is done for, almost always, no immediate benefit.
> Changing those places to use
>     depends on FW_LOADER
> 
> should have no effect, I think. Except for the EXPERT people not wanting
> FW_LOADER. But that would be putting the burden where it belongs, I'd
> say.

Paul, how would you recommend we proceed with this? Should we go ahead and
change all 'select FW_LOADER' to 'depends on' ? If not does this need to be
fixed on kconfig?

 Luis

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Thu, May 07, 2015 at 08:06:35PM +0200, Paul Bolle wrote:
> See, FW_LOADER is 'y' unless EXPERT is set and one goes to the trouble
> of setting FW_LOADER to 'n'. So in the 100+ places where FW_LOADER is
> selected, that is done for, almost always, no immediate benefit.
> Changing those places to use
>     depends on FW_LOADER
> 
> should have no effect, I think. Except for the EXPERT people not wanting
> FW_LOADER. But that would be putting the burden where it belongs, I'd
> say.

Paul, how would you recommend we proceed with this? Should we go ahead and
change all 'select FW_LOADER' to 'depends on' ? If not does this need to be
fixed on kconfig?

 Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

Hi Luis,

On Mon, 2015-05-18 at 22:01 +0200, Luis R. Rodriguez wrote:
> On Thu, May 07, 2015 at 08:06:35PM +0200, Paul Bolle wrote:
> > See, FW_LOADER is 'y' unless EXPERT is set and one goes to the trouble
> > of setting FW_LOADER to 'n'. So in the 100+ places where FW_LOADER is
> > selected, that is done for, almost always, no immediate benefit.
> > Changing those places to use
> >     depends on FW_LOADER
> > 
> > should have no effect, I think. Except for the EXPERT people not wanting
> > FW_LOADER. But that would be putting the burden where it belongs, I'd
> > say.
> 
> Paul, how would you recommend we proceed with this? Should we go ahead and
> change all 'select FW_LOADER' to 'depends on' ?

I've kept you waiting. That was impolite.

Two things I've discovered in the last few days. One is, sort of,
interesting and the other is specific to your issue.

1) Since v2.6.36 the recursive error reported by kconfig became more
informative. See commit d595cea62403 ("kconfig: print more info when we
see a recursive dependency").

There have been 20 commits that bothered to include "recursive
dependency detected" in the commit explanation since v2.6.36. All of
those were about dependencies that involved at least one "select"
statement. The most common solution was to convert one "select" to a
"depends on".

So a, highly unscientific, guideline for recursive dependency issues
would be: convert a "select" to a "depends on".

2) I stumbled on commit d9b19199e489 ("always enable FW_LOADER unless
EMBEDDED=y"). In the commit explanation I spotted:
    As a bonus, we can then get rid of all "select FW_LOADER" [...].

It seems the plan to get rid of those never materialized.

So what's the TL;DR?

It's hard to generate a .config with "# CONFIG_FW_LOADER is not set".
One has to set EXPERT, disable FW_LOADER manually, and never set one of
the over 100 symbols that select FW_LOADER. So, probably, almost
all .config files have FW_LOADER set. So I think, except for some corner
cases, either converting all "select FW_LOADER" to "depends on
FW_LOADER" or simply dropping  "select FW_LOADER" all together, should
be fine.

Those corner cases should then be handled on a case by case basis. 

> If not does this need to be fixed on kconfig?

There's no reason to think the logic of the kconfig tools, as it is
currently implemented, is flawed. Feel free to convince me of the
opposite.

Thanks,

Paul Bolle

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

Hi Luis,

On Mon, 2015-05-18 at 22:01 +0200, Luis R. Rodriguez wrote:
> On Thu, May 07, 2015 at 08:06:35PM +0200, Paul Bolle wrote:
> > See, FW_LOADER is 'y' unless EXPERT is set and one goes to the trouble
> > of setting FW_LOADER to 'n'. So in the 100+ places where FW_LOADER is
> > selected, that is done for, almost always, no immediate benefit.
> > Changing those places to use
> >     depends on FW_LOADER
> > 
> > should have no effect, I think. Except for the EXPERT people not wanting
> > FW_LOADER. But that would be putting the burden where it belongs, I'd
> > say.
> 
> Paul, how would you recommend we proceed with this? Should we go ahead and
> change all 'select FW_LOADER' to 'depends on' ?

I've kept you waiting. That was impolite.

Two things I've discovered in the last few days. One is, sort of,
interesting and the other is specific to your issue.

1) Since v2.6.36 the recursive error reported by kconfig became more
informative. See commit d595cea62403 ("kconfig: print more info when we
see a recursive dependency").

There have been 20 commits that bothered to include "recursive
dependency detected" in the commit explanation since v2.6.36. All of
those were about dependencies that involved at least one "select"
statement. The most common solution was to convert one "select" to a
"depends on".

So a, highly unscientific, guideline for recursive dependency issues
would be: convert a "select" to a "depends on".

2) I stumbled on commit d9b19199e489 ("always enable FW_LOADER unless
EMBEDDED=y"). In the commit explanation I spotted:
    As a bonus, we can then get rid of all "select FW_LOADER" [...].

It seems the plan to get rid of those never materialized.

So what's the TL;DR?

It's hard to generate a .config with "# CONFIG_FW_LOADER is not set".
One has to set EXPERT, disable FW_LOADER manually, and never set one of
the over 100 symbols that select FW_LOADER. So, probably, almost
all .config files have FW_LOADER set. So I think, except for some corner
cases, either converting all "select FW_LOADER" to "depends on
FW_LOADER" or simply dropping  "select FW_LOADER" all together, should
be fine.

Those corner cases should then be handled on a case by case basis. 

> If not does this need to be fixed on kconfig?

There's no reason to think the logic of the kconfig tools, as it is
currently implemented, is flawed. Feel free to convince me of the
opposite.

Thanks,

Paul Bolle


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Mon, May 18, 2015 at 10:45:30PM +0200, Paul Bolle wrote:
> [...] so, probably, almost
> all .config files have FW_LOADER set. So I think, except for some corner
> cases, either converting all "select FW_LOADER" to "depends on
> FW_LOADER" or simply dropping  "select FW_LOADER" all together, should
> be fine.

Well, that makes sense. I just dropped all "select FW_LOADER" entries
on next-20150518, then I enabled everything with 'make allyesconfig'
and then went into menuconfig to disable FW_LOADER. The build worked.

Going to try a few more build matrix combinations and send patches to
do away with this.

> Those corner cases should then be handled on a case by case basis. 
> 
> > If not does this need to be fixed on kconfig?
> 
> There's no reason to think the logic of the kconfig tools, as it is
> currently implemented, is flawed. Feel free to convince me of the
> opposite.

Very well, thanks so much for your review and help.

  Luis

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Mon, May 18, 2015 at 10:45:30PM +0200, Paul Bolle wrote:
> [...] so, probably, almost
> all .config files have FW_LOADER set. So I think, except for some corner
> cases, either converting all "select FW_LOADER" to "depends on
> FW_LOADER" or simply dropping  "select FW_LOADER" all together, should
> be fine.

Well, that makes sense. I just dropped all "select FW_LOADER" entries
on next-20150518, then I enabled everything with 'make allyesconfig'
and then went into menuconfig to disable FW_LOADER. The build worked.

Going to try a few more build matrix combinations and send patches to
do away with this.

> Those corner cases should then be handled on a case by case basis. 
> 
> > If not does this need to be fixed on kconfig?
> 
> There's no reason to think the logic of the kconfig tools, as it is
> currently implemented, is flawed. Feel free to convince me of the
> opposite.

Very well, thanks so much for your review and help.

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

On Tue, 2015-05-19 at 02:09 +0200, Luis R. Rodriguez wrote:
> On Mon, May 18, 2015 at 10:45:30PM +0200, Paul Bolle wrote:
> > [...] so, probably, almost
> > all .config files have FW_LOADER set. So I think, except for some corner
> > cases, either converting all "select FW_LOADER" to "depends on
> > FW_LOADER" or simply dropping  "select FW_LOADER" all together, should
> > be fine.
> 
> Well, that makes sense. I just dropped all "select FW_LOADER" entries
> on next-20150518, then I enabled everything with 'make allyesconfig'
> and then went into menuconfig to disable FW_LOADER. The build worked.
> 
> Going to try a few more build matrix combinations and send patches to
> do away with this.
> 
> > Those corner cases should then be handled on a case by case basis. 

Having slept on this, it occurred to me a randconfig could hit those
corner cases. (Make that will hit them, actually.) Of course, one might
argue that randconfig and EXPERT's advice, "Only use this if you really
know what you are doing.", are at odds. Which opens another can of
worms: how much do we care about .config files in which randconfig
visited the kernels darker corners? Just enough, I'm afraid.

So it seems I've wasted your time by suggesting to drop those selects.
And now I wonder what trouble using "depends on" will generate here...


Paul Bolle

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

On Tue, 2015-05-19 at 02:09 +0200, Luis R. Rodriguez wrote:
> On Mon, May 18, 2015 at 10:45:30PM +0200, Paul Bolle wrote:
> > [...] so, probably, almost
> > all .config files have FW_LOADER set. So I think, except for some corner
> > cases, either converting all "select FW_LOADER" to "depends on
> > FW_LOADER" or simply dropping  "select FW_LOADER" all together, should
> > be fine.
> 
> Well, that makes sense. I just dropped all "select FW_LOADER" entries
> on next-20150518, then I enabled everything with 'make allyesconfig'
> and then went into menuconfig to disable FW_LOADER. The build worked.
> 
> Going to try a few more build matrix combinations and send patches to
> do away with this.
> 
> > Those corner cases should then be handled on a case by case basis. 

Having slept on this, it occurred to me a randconfig could hit those
corner cases. (Make that will hit them, actually.) Of course, one might
argue that randconfig and EXPERT's advice, "Only use this if you really
know what you are doing.", are at odds. Which opens another can of
worms: how much do we care about .config files in which randconfig
visited the kernels darker corners? Just enough, I'm afraid.

So it seems I've wasted your time by suggesting to drop those selects.
And now I wonder what trouble using "depends on" will generate here...


Paul Bolle


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Tue, May 19, 2015 at 10:02:15AM +0200, Paul Bolle wrote:
> On Tue, 2015-05-19 at 02:09 +0200, Luis R. Rodriguez wrote:
> > On Mon, May 18, 2015 at 10:45:30PM +0200, Paul Bolle wrote:
> > > [...] so, probably, almost
> > > all .config files have FW_LOADER set. So I think, except for some corner
> > > cases, either converting all "select FW_LOADER" to "depends on
> > > FW_LOADER" or simply dropping  "select FW_LOADER" all together, should
> > > be fine.
> > 
> > Well, that makes sense. I just dropped all "select FW_LOADER" entries
> > on next-20150518, then I enabled everything with 'make allyesconfig'
> > and then went into menuconfig to disable FW_LOADER. The build worked.
> > 
> > Going to try a few more build matrix combinations and send patches to
> > do away with this.
> > 
> > > Those corner cases should then be handled on a case by case basis. 
> 
> Having slept on this, it occurred to me a randconfig could hit those
> corner cases. (Make that will hit them, actually.) Of course, one might
> argue that randconfig and EXPERT's advice, "Only use this if you really
> know what you are doing.", are at odds. Which opens another can of
> worms: how much do we care about .config files in which randconfig
> visited the kernels darker corners? Just enough, I'm afraid.
> 
> So it seems I've wasted your time by suggesting to drop those selects.

IMHO not at all.

> And now I wonder what trouble using "depends on" will generate here...

Instead of depends on we should just drop it and and issues arise we
should fix them provided an allyesconfig and allmodconfig work when
FW_LOADER is disabled. That was the approach I wanted to take at
least. To make this easier to phase we can break it down by subsystem.

Thoughts?

 Luis

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Tue, May 19, 2015 at 10:02:15AM +0200, Paul Bolle wrote:
> On Tue, 2015-05-19 at 02:09 +0200, Luis R. Rodriguez wrote:
> > On Mon, May 18, 2015 at 10:45:30PM +0200, Paul Bolle wrote:
> > > [...] so, probably, almost
> > > all .config files have FW_LOADER set. So I think, except for some corner
> > > cases, either converting all "select FW_LOADER" to "depends on
> > > FW_LOADER" or simply dropping  "select FW_LOADER" all together, should
> > > be fine.
> > 
> > Well, that makes sense. I just dropped all "select FW_LOADER" entries
> > on next-20150518, then I enabled everything with 'make allyesconfig'
> > and then went into menuconfig to disable FW_LOADER. The build worked.
> > 
> > Going to try a few more build matrix combinations and send patches to
> > do away with this.
> > 
> > > Those corner cases should then be handled on a case by case basis. 
> 
> Having slept on this, it occurred to me a randconfig could hit those
> corner cases. (Make that will hit them, actually.) Of course, one might
> argue that randconfig and EXPERT's advice, "Only use this if you really
> know what you are doing.", are at odds. Which opens another can of
> worms: how much do we care about .config files in which randconfig
> visited the kernels darker corners? Just enough, I'm afraid.
> 
> So it seems I've wasted your time by suggesting to drop those selects.

IMHO not at all.

> And now I wonder what trouble using "depends on" will generate here...

Instead of depends on we should just drop it and and issues arise we
should fix them provided an allyesconfig and allmodconfig work when
FW_LOADER is disabled. That was the approach I wanted to take at
least. To make this easier to phase we can break it down by subsystem.

Thoughts?

 Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Herbert Xu]

On Tue, May 19, 2015 at 05:46:30PM +0200, Luis R. Rodriguez wrote:
>
> Instead of depends on we should just drop it and and issues arise we
> should fix them provided an allyesconfig and allmodconfig work when
> FW_LOADER is disabled. That was the approach I wanted to take at
> least. To make this easier to phase we can break it down by subsystem.

Modules select FW_LOADER because they call request_firmware.

If you disable FW_LOADER then every case will result in a build
failure.  So you must either have a select or a depends on.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Herbert Xu]

On Tue, May 19, 2015 at 05:46:30PM +0200, Luis R. Rodriguez wrote:
>
> Instead of depends on we should just drop it and and issues arise we
> should fix them provided an allyesconfig and allmodconfig work when
> FW_LOADER is disabled. That was the approach I wanted to take at
> least. To make this easier to phase we can break it down by subsystem.

Modules select FW_LOADER because they call request_firmware.

If you disable FW_LOADER then every case will result in a build
failure.  So you must either have a select or a depends on.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Herbert Xu]

On Wed, May 20, 2015 at 06:59:45AM +0800, Herbert Xu wrote:
> 
> If you disable FW_LOADER then every case will result in a build
> failure.  So you must either have a select or a depends on.

OK I was wrong.  It should still compile.  So I guess you only
need the depends on/select for those that won't work without the
firmware.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Herbert Xu]

On Wed, May 20, 2015 at 06:59:45AM +0800, Herbert Xu wrote:
> 
> If you disable FW_LOADER then every case will result in a build
> failure.  So you must either have a select or a depends on.

OK I was wrong.  It should still compile.  So I guess you only
need the depends on/select for those that won't work without the
firmware.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Tue, May 19, 2015 at 4:03 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> OK I was wrong.  It should still compile

Right.

> So I guess you only
> need the depends on/select for those that won't work without the
> firmware.

Well that's be true if FW_LOADER was easy to disable, but its not. You
really gotta try hard to disable it. Not only does it require EXPERT
but also EMBEDDED. I think its fair to say if you disable FW_LOADER
you know what you are doing and its fair for us then to remove such
selects or depends. Thoughts?

  Luis

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Tue, May 19, 2015 at 4:03 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> OK I was wrong.  It should still compile

Right.

> So I guess you only
> need the depends on/select for those that won't work without the
> firmware.

Well that's be true if FW_LOADER was easy to disable, but its not. You
really gotta try hard to disable it. Not only does it require EXPERT
but also EMBEDDED. I think its fair to say if you disable FW_LOADER
you know what you are doing and its fair for us then to remove such
selects or depends. Thoughts?

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Tue, May 19, 2015 at 4:03 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> OK I was wrong.  It should still compile

Right.

> So I guess you only
> need the depends on/select for those that won't work without the
> firmware.

Well that's be true if FW_LOADER was easy to disable, but its not. You
really gotta try hard to disable it. Not only does it require EXPERT
but also EMBEDDED. I think its fair to say if you disable FW_LOADER
you know what you are doing and its fair for us then to remove such
selects or depends. Thoughts?

  Luis

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Herbert Xu]

On Tue, May 19, 2015 at 04:05:43PM -0700, Luis R. Rodriguez wrote:
> 
> Well that's be true if FW_LOADER was easy to disable, but its not. You
> really gotta try hard to disable it. Not only does it require EXPERT
> but also EMBEDDED. I think its fair to say if you disable FW_LOADER
> you know what you are doing and its fair for us then to remove such
> selects or depends. Thoughts?

Sure.  I can live with killing all selects/depends on FW_LOADER.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Herbert Xu]

On Tue, May 19, 2015 at 04:05:43PM -0700, Luis R. Rodriguez wrote:
> 
> Well that's be true if FW_LOADER was easy to disable, but its not. You
> really gotta try hard to disable it. Not only does it require EXPERT
> but also EMBEDDED. I think its fair to say if you disable FW_LOADER
> you know what you are doing and its fair for us then to remove such
> selects or depends. Thoughts?

Sure.  I can live with killing all selects/depends on FW_LOADER.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Herbert Xu]

On Tue, May 19, 2015 at 04:05:43PM -0700, Luis R. Rodriguez wrote:
> 
> Well that's be true if FW_LOADER was easy to disable, but its not. You
> really gotta try hard to disable it. Not only does it require EXPERT
> but also EMBEDDED. I think its fair to say if you disable FW_LOADER
> you know what you are doing and its fair for us then to remove such
> selects or depends. Thoughts?

Sure.  I can live with killing all selects/depends on FW_LOADER.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

On Wed, 2015-05-20 at 10:49 +0800, Herbert Xu wrote:
> On Tue, May 19, 2015 at 04:05:43PM -0700, Luis R. Rodriguez wrote: 
> > Well that's be true if FW_LOADER was easy to disable, but its not. You
> > really gotta try hard to disable it. Not only does it require EXPERT
> > but also EMBEDDED.

How does that require EMBEDDED?

>  I think its fair to say if you disable FW_LOADER
> > you know what you are doing and its fair for us then to remove such
> > selects or depends. Thoughts?
> 
> Sure.  I can live with killing all selects/depends on FW_LOADER.

(Having reread my mail from the day before yesterday once more, I note
that my suggestion to drop the selects is rather circular. Because it's
the selects that also make it hard to disable FW_LOADER.)

So the message is something like: "If you set EXPERT and disable
FW_LOADER you're on your own. You have to figure out yourself whether
the configuration you chose builds or actually runs correctly. Don't
expect us to care about the issues you run into. And that goes for
randconfig builds that happen to do that too."

That might be an acceptable thing to say. The help for EXPERT is pretty
clear. But I do wonder if this is a first or if this has been done
before (ie, whether there's a precedent). Because, generally speaking,
people try rather hard to prevent pointless configurations.


Paul Bolle

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

On Wed, 2015-05-20 at 10:49 +0800, Herbert Xu wrote:
> On Tue, May 19, 2015 at 04:05:43PM -0700, Luis R. Rodriguez wrote: 
> > Well that's be true if FW_LOADER was easy to disable, but its not. You
> > really gotta try hard to disable it. Not only does it require EXPERT
> > but also EMBEDDED.

How does that require EMBEDDED?

>  I think its fair to say if you disable FW_LOADER
> > you know what you are doing and its fair for us then to remove such
> > selects or depends. Thoughts?
> 
> Sure.  I can live with killing all selects/depends on FW_LOADER.

(Having reread my mail from the day before yesterday once more, I note
that my suggestion to drop the selects is rather circular. Because it's
the selects that also make it hard to disable FW_LOADER.)

So the message is something like: "If you set EXPERT and disable
FW_LOADER you're on your own. You have to figure out yourself whether
the configuration you chose builds or actually runs correctly. Don't
expect us to care about the issues you run into. And that goes for
randconfig builds that happen to do that too."

That might be an acceptable thing to say. The help for EXPERT is pretty
clear. But I do wonder if this is a first or if this has been done
before (ie, whether there's a precedent). Because, generally speaking,
people try rather hard to prevent pointless configurations.


Paul Bolle


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Paul Bolle]

On Wed, 2015-05-20 at 10:49 +0800, Herbert Xu wrote:
> On Tue, May 19, 2015 at 04:05:43PM -0700, Luis R. Rodriguez wrote: 
> > Well that's be true if FW_LOADER was easy to disable, but its not. You
> > really gotta try hard to disable it. Not only does it require EXPERT
> > but also EMBEDDED.

How does that require EMBEDDED?

>  I think its fair to say if you disable FW_LOADER
> > you know what you are doing and its fair for us then to remove such
> > selects or depends. Thoughts?
> 
> Sure.  I can live with killing all selects/depends on FW_LOADER.

(Having reread my mail from the day before yesterday once more, I note
that my suggestion to drop the selects is rather circular. Because it's
the selects that also make it hard to disable FW_LOADER.)

So the message is something like: "If you set EXPERT and disable
FW_LOADER you're on your own. You have to figure out yourself whether
the configuration you chose builds or actually runs correctly. Don't
expect us to care about the issues you run into. And that goes for
randconfig builds that happen to do that too."

That might be an acceptable thing to say. The help for EXPERT is pretty
clear. But I do wonder if this is a first or if this has been done
before (ie, whether there's a precedent). Because, generally speaking,
people try rather hard to prevent pointless configurations.


Paul Bolle

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Wed, May 20, 2015 at 11:00:55AM +0200, Paul Bolle wrote:
> On Wed, 2015-05-20 at 10:49 +0800, Herbert Xu wrote:
> > On Tue, May 19, 2015 at 04:05:43PM -0700, Luis R. Rodriguez wrote: 
> > > Well that's be true if FW_LOADER was easy to disable, but its not. You
> > > really gotta try hard to disable it. Not only does it require EXPERT
> > > but also EMBEDDED.
> 
> How does that require EMBEDDED?

Sorry not embedded, not sure where I got that from, for some reason
I though you had mentioned that.

> >  I think its fair to say if you disable FW_LOADER
> > > you know what you are doing and its fair for us then to remove such
> > > selects or depends. Thoughts?
> > 
> > Sure.  I can live with killing all selects/depends on FW_LOADER.
> 
> (Having reread my mail from the day before yesterday once more, I note
> that my suggestion to drop the selects is rather circular. Because it's
> the selects that also make it hard to disable FW_LOADER.)
> 
> So the message is something like: "If you set EXPERT and disable
> FW_LOADER you're on your own. You have to figure out yourself whether
> the configuration you chose builds

I think we can attest that it will build, otherwise we should fix.

> or actually runs correctly.

Whether it will run in this case will depend on whether or not
the firmware was needed or not, if it was it won't. Note that
there is a FW API call which implies "this is optional firmware",
its the request_firmware_direct() call but this call is synchronous,
we have no option for asynchronous behaviour. I intend to add support
for that but that requires a bit of changes. Also, based on my review
its a fair assumption that most calls to the FW APIs mean they need
it. The only ones we can be sure are optional are the ones using
request_firmware_direct().

> Don't
> expect us to care about the issues you run into. And that goes for
> randconfig builds that happen to do that too."

I think its fair to expect us to fix randconfig build issues, but not
runtime issues.

> That might be an acceptable thing to say. The help for EXPERT is pretty
> clear. But I do wonder if this is a first or if this has been done
> before (ie, whether there's a precedent). Because, generally speaking,
> people try rather hard to prevent pointless configurations.

Yeah sure, we even let your system go out of regulatory compliance,
see CFG80211_CERTIFICATION_ONUS, and CFG80211_REG_CELLULAR_HINTS.
Then with CFG80211_INTERNAL_REGDB the parser right now lacks support
for a few new bells and whistles and requires expert knowledge how
to properly build and integrate all new bells and whistles. It seemed
folks were OK with this.

  Luis

Re: [wireless-regdb] [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Wed, May 20, 2015 at 11:00:55AM +0200, Paul Bolle wrote:
> On Wed, 2015-05-20 at 10:49 +0800, Herbert Xu wrote:
> > On Tue, May 19, 2015 at 04:05:43PM -0700, Luis R. Rodriguez wrote: 
> > > Well that's be true if FW_LOADER was easy to disable, but its not. You
> > > really gotta try hard to disable it. Not only does it require EXPERT
> > > but also EMBEDDED.
> 
> How does that require EMBEDDED?

Sorry not embedded, not sure where I got that from, for some reason
I though you had mentioned that.

> >  I think its fair to say if you disable FW_LOADER
> > > you know what you are doing and its fair for us then to remove such
> > > selects or depends. Thoughts?
> > 
> > Sure.  I can live with killing all selects/depends on FW_LOADER.
> 
> (Having reread my mail from the day before yesterday once more, I note
> that my suggestion to drop the selects is rather circular. Because it's
> the selects that also make it hard to disable FW_LOADER.)
> 
> So the message is something like: "If you set EXPERT and disable
> FW_LOADER you're on your own. You have to figure out yourself whether
> the configuration you chose builds

I think we can attest that it will build, otherwise we should fix.

> or actually runs correctly.

Whether it will run in this case will depend on whether or not
the firmware was needed or not, if it was it won't. Note that
there is a FW API call which implies "this is optional firmware",
its the request_firmware_direct() call but this call is synchronous,
we have no option for asynchronous behaviour. I intend to add support
for that but that requires a bit of changes. Also, based on my review
its a fair assumption that most calls to the FW APIs mean they need
it. The only ones we can be sure are optional are the ones using
request_firmware_direct().

> Don't
> expect us to care about the issues you run into. And that goes for
> randconfig builds that happen to do that too."

I think its fair to expect us to fix randconfig build issues, but not
runtime issues.

> That might be an acceptable thing to say. The help for EXPERT is pretty
> clear. But I do wonder if this is a first or if this has been done
> before (ie, whether there's a precedent). Because, generally speaking,
> people try rather hard to prevent pointless configurations.

Yeah sure, we even let your system go out of regulatory compliance,
see CFG80211_CERTIFICATION_ONUS, and CFG80211_REG_CELLULAR_HINTS.
Then with CFG80211_INTERNAL_REGDB the parser right now lacks support
for a few new bells and whistles and requires expert knowledge how
to properly build and integrate all new bells and whistles. It seemed
folks were OK with this.

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 03/12] crypto: qat - address recursive dependency when fw signing is enabled

[Luis R. Rodriguez]

On Wed, May 20, 2015 at 11:00:55AM +0200, Paul Bolle wrote:
> On Wed, 2015-05-20 at 10:49 +0800, Herbert Xu wrote:
> > On Tue, May 19, 2015 at 04:05:43PM -0700, Luis R. Rodriguez wrote: 
> > > Well that's be true if FW_LOADER was easy to disable, but its not. You
> > > really gotta try hard to disable it. Not only does it require EXPERT
> > > but also EMBEDDED.
> 
> How does that require EMBEDDED?

Sorry not embedded, not sure where I got that from, for some reason
I though you had mentioned that.

> >  I think its fair to say if you disable FW_LOADER
> > > you know what you are doing and its fair for us then to remove such
> > > selects or depends. Thoughts?
> > 
> > Sure.  I can live with killing all selects/depends on FW_LOADER.
> 
> (Having reread my mail from the day before yesterday once more, I note
> that my suggestion to drop the selects is rather circular. Because it's
> the selects that also make it hard to disable FW_LOADER.)
> 
> So the message is something like: "If you set EXPERT and disable
> FW_LOADER you're on your own. You have to figure out yourself whether
> the configuration you chose builds

I think we can attest that it will build, otherwise we should fix.

> or actually runs correctly.

Whether it will run in this case will depend on whether or not
the firmware was needed or not, if it was it won't. Note that
there is a FW API call which implies "this is optional firmware",
its the request_firmware_direct() call but this call is synchronous,
we have no option for asynchronous behaviour. I intend to add support
for that but that requires a bit of changes. Also, based on my review
its a fair assumption that most calls to the FW APIs mean they need
it. The only ones we can be sure are optional are the ones using
request_firmware_direct().

> Don't
> expect us to care about the issues you run into. And that goes for
> randconfig builds that happen to do that too."

I think its fair to expect us to fix randconfig build issues, but not
runtime issues.

> That might be an acceptable thing to say. The help for EXPERT is pretty
> clear. But I do wonder if this is a first or if this has been done
> before (ie, whether there's a precedent). Because, generally speaking,
> people try rather hard to prevent pointless configurations.

Yeah sure, we even let your system go out of regulatory compliance,
see CFG80211_CERTIFICATION_ONUS, and CFG80211_REG_CELLULAR_HINTS.
Then with CFG80211_INTERNAL_REGDB the parser right now lacks support
for a few new bells and whistles and requires expert knowledge how
to properly build and integrate all new bells and whistles. It seemed
folks were OK with this.

  Luis

[PATCH v1 04/12] firmware: fix possible use after free on name on asynchronous request

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Asynchronous firmware loading copies the pointer to the
name passed as an argument only to be scheduled later and
used. This behaviour works well for synchronous calling
but in asynchronous mode there's a chance the caller could
immediately free the passed string after making the
asynchronous call. This could trigger a use after free
having the kernel look on disk for arbitrary file names.

In order to force-test the issue you can use a test-driver
designed to illustrate this issue on github [0], use the
next-20150505-fix-use-after-free branch.

With this patch applied you get:

[  283.512445] firmware name: test_module_stuff.bin
[  287.514020] firmware name: test_module_stuff.bin
[  287.532489] firmware found

Without this patch applied you can end up with something such as:

[  135.624216] firmware name: \xffffff80BJ
[  135.624249] platform fake-dev.0: Direct firmware load for \xffffff80Bi failed with error -2
[  135.624252] No firmware found
[  135.624252] firmware found

Unfortunatley in the worst and most common case however you
can typically crash your system with a page fault by trying to
free something which you cannot, and/or a NULL pointer
dereference [1].

The fix and issue using schedule_work() for asynchronous
runs is generalized in the following SmPL grammar patch,
when applied to next-20150505 only the firmware_class
code is affected. This grammar patch can and should further
be generalized to vet for for other kernel asynchronous
mechanisms.

@ calls_schedule_work @
type T;
T *priv_work;
identifier func, work_func;
identifier work;
identifier priv_name, name;
statement S;
expression gfp;
@@

 func(..., const char *name, ...)
 {
 	...
 	priv_work = kzalloc(sizeof(T), gfp);
 	...
-	priv_work->priv_name = name;
+	priv_work->priv_name = kstrdup_const(name, gfp);
	...
(... when any
 	if (...)
 	{
 		...
+ 		kfree_const(priv_work->priv_name);
 		kfree(priv_work);
		...
 	}
) ... when any
 	INIT_WORK(&priv_work->work, work_func);
 	...
 	schedule_work(&priv_work->work);
 	...
 }

@ the_work_func depends on calls_schedule_work @
type calls_schedule_work.T;
T *priv_work;
identifier calls_schedule_work.work_func;
identifier calls_schedule_work.priv_name;
identifier calls_schedule_work.work;
identifier some_work;
@@

 work_func(...)
 {
 	...
 	priv_work = container_of(some_work, T, work);
 	...
+	kfree_const(priv_work->priv_name);
 	kfree(priv_work);
 	...
 }

[0] https://github.com/mcgrof/fake-firmware-test.git
[1] The following kernel ring buffer splat:

firmware name: test_module_stuff.bin
firmware name:
firmware found
general protection fault: 0000 [#1] SMP
Modules linked in: test(O) <...etc-it-does-not-matter>
 drm sr_mod cdrom xhci_pci xhci_hcd rtsx_pci mfd_core video button sg
CPU: 3 PID: 87 Comm: kworker/3:2 Tainted: G           O    4.0.0-00010-g22b5bb0-dirty #176
Hardware name: LENOVO 20AW000LUS/20AW000LUS, BIOS GLET43WW (1.18 ) 12/04/2013
Workqueue: events request_firmware_work_func
task: ffff8800c7f8e290 ti: ffff8800c7f94000 task.ti: ffff8800c7f94000
RIP: 0010:[<ffffffff814a586c>]  [<ffffffff814a586c>] fw_free_buf+0xc/0x40
RSP: 0000:ffff8800c7f97d78  EFLAGS: 00010286
RAX: ffffffff81ae3700 RBX: ffffffff816d1181 RCX: 0000000000000006
RDX: 0001ee850ff68500 RSI: 0000000000000246 RDI: c35d5f415e415d41
RBP: ffff8800c7f97d88 R08: 000000000000000a R09: 0000000000000000
R10: 0000000000000358 R11: ffff8800c7f97a7e R12: ffff8800c7ec1e80
R13: ffff88021e2d4cc0 R14: ffff88021e2dff00 R15: 00000000000000c0
FS:  0000000000000000(0000) GS:ffff88021e2c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000034b8cd8 CR3: 000000021073c000 CR4: 00000000001407e0
Stack:
 ffffffff816d1181 ffff8800c7ec1e80 ffff8800c7f97da8 ffffffff814a58f8
 000000000000000a ffffffff816d1181 ffff8800c7f97dc8 ffffffffa047002c
 ffff88021e2dff00 ffff8802116ac1c0 ffff8800c7f97df8 ffffffff814a65fe
Call Trace:
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff814a58f8>] release_firmware+0x58/0x80
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffffa047002c>] test_mod_cb+0x2c/0x43 [test]
 [<ffffffff814a65fe>] request_firmware_work_func+0x5e/0x80
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff8108d23a>] process_one_work+0x14a/0x3f0
 [<ffffffff8108d911>] worker_thread+0x121/0x460
 [<ffffffff8108d7f0>] ? rescuer_thread+0x310/0x310
 [<ffffffff810928f9>] kthread+0xc9/0xe0
 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
 [<ffffffff816d52d8>] ret_from_fork+0x58/0x90
 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
Code: c7 c6 dd ad a3 81 48 c7 c7 20 97 ce 81 31 c0 e8 0b b2 ed ff e9 78 ff ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 54 53 <4c> 8b 67 38 48 89 fb 4c 89 e7 e8 85 f7 22 00 f0 83 2b 01 74 0f
RIP  [<ffffffff814a586c>] fw_free_buf+0xc/0x40
 RSP <ffff8800c7f97d78>
---[ end trace 4e62c56a58d0eac1 ]---
BUG: unable to handle kernel paging request at ffffffffffffffd8
IP: [<ffffffff81093ee0>] kthread_data+0x10/0x20
PGD 1c13067 PUD 1c15067 PMD 0
Oops: 0000 [#2] SMP
Modules linked in: test(O) <...etc-it-does-not-matter>
 drm sr_mod cdrom xhci_pci xhci_hcd rtsx_pci mfd_core video button sg
CPU: 3 PID: 87 Comm: kworker/3:2 Tainted: G      D    O    4.0.0-00010-g22b5bb0-dirty #176
Hardware name: LENOVO 20AW000LUS/20AW000LUS, BIOS GLET43WW (1.18 ) 12/04/2013
task: ffff8800c7f8e290 ti: ffff8800c7f94000 task.ti: ffff8800c7f94000
RIP: 0010:[<ffffffff81092ee0>]  [<ffffffff81092ee0>] kthread_data+0x10/0x20
RSP: 0018:ffff8800c7f97b18  EFLAGS: 00010096
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 000000000000000d
RDX: 0000000000000003 RSI: 0000000000000003 RDI: ffff8800c7f8e290
RBP: ffff8800c7f97b18 R08: 000000000000bc00 R09: 0000000000007e76
R10: 0000000000000001 R11: 000000000000002f R12: ffff8800c7f8e290
R13: 00000000000154c0 R14: 0000000000000003 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88021e2c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000028 CR3: 0000000210675000 CR4: 00000000001407e0
Stack:
 ffff8800c7f97b38 ffffffff8108dcd5 ffff8800c7f97b38 ffff88021e2d54c0
 ffff8800c7f97b88 ffffffff816d1500 ffff880213d42368 ffff8800c7f8e290
 ffff8800c7f97b88 ffff8800c7f97fd8 ffff8800c7f8e710 0000000000000246
Call Trace:
 [<ffffffff8108dcd5>] wq_worker_sleeping+0x15/0xa0
 [<ffffffff816d1500>] __schedule+0x6e0/0x940
 [<ffffffff816d1797>] schedule+0x37/0x90
 [<ffffffff810779bc>] do_exit+0x6bc/0xb40
 [<ffffffff8101898f>] oops_end+0x9f/0xe0
 [<ffffffff81018efb>] die+0x4b/0x70
 [<ffffffff81015622>] do_general_protection+0xe2/0x170
 [<ffffffff816d74e8>] general_protection+0x28/0x30
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff814a586c>] ? fw_free_buf+0xc/0x40
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff814a58f8>] release_firmware+0x58/0x80
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffffa047002c>] test_mod_cb+0x2c/0x43 [test]
 [<ffffffff814a65fe>] request_firmware_work_func+0x5e/0x80
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff8108d23a>] process_one_work+0x14a/0x3f0
 [<ffffffff8108d911>] worker_thread+0x121/0x460
 [<ffffffff8108d7f0>] ? rescuer_thread+0x310/0x310
 [<ffffffff810928f9>] kthread+0xc9/0xe0
 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
 [<ffffffff816d52d8>] ret_from_fork+0x58/0x90
 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
Code: 00 48 89 e5 5d 48 8b 40 c8 48 c1 e8 02 83 e0 01 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 87 30 05 00 00 55 48 89 e5 <48> 8b 40 d8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
RIP  [<ffffffff81092ee0>] kthread_data+0x10/0x20
 RSP <ffff8800c7f97b18>
CR2: ffffffffffffffd8
---[ end trace 4e62c56a58d0eac2 ]---
Fixing recursive fault but reboot is needed!

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Cc: stable@vger.kernel.org
Cc: cocci@systeme.lip6.fr
Generated-by: Coccinelle SmPL
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/base/firmware_class.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 6c5c9ed..2e85860 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1242,6 +1242,7 @@ static void request_firmware_work_func(struct work_struct *work)
 	put_device(fw_work->device); /* taken in request_firmware_nowait() */
 
 	module_put(fw_work->module);
+	kfree_const(fw_work->name);
 	kfree(fw_work);
 }
 
@@ -1281,7 +1282,7 @@ request_firmware_nowait(
 		return -ENOMEM;
 
 	fw_work->module = module;
-	fw_work->name = name;
+	fw_work->name = kstrdup_const(name, gfp);
 	fw_work->device = device;
 	fw_work->context = context;
 	fw_work->cont = cont;
@@ -1289,6 +1290,7 @@ request_firmware_nowait(
 		(uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
 
 	if (!try_module_get(module)) {
+		kfree_const(fw_work->name);
 		kfree(fw_work);
 		return -EFAULT;
 	}
-- 
2.3.2.209.gd67f9d5.dirty

[wireless-regdb] [PATCH v1 04/12] firmware: fix possible use after free on name on asynchronous request

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Asynchronous firmware loading copies the pointer to the
name passed as an argument only to be scheduled later and
used. This behaviour works well for synchronous calling
but in asynchronous mode there's a chance the caller could
immediately free the passed string after making the
asynchronous call. This could trigger a use after free
having the kernel look on disk for arbitrary file names.

In order to force-test the issue you can use a test-driver
designed to illustrate this issue on github [0], use the
next-20150505-fix-use-after-free branch.

With this patch applied you get:

[  283.512445] firmware name: test_module_stuff.bin
[  287.514020] firmware name: test_module_stuff.bin
[  287.532489] firmware found

Without this patch applied you can end up with something such as:

[  135.624216] firmware name: \xffffff80BJ
[  135.624249] platform fake-dev.0: Direct firmware load for \xffffff80Bi failed with error -2
[  135.624252] No firmware found
[  135.624252] firmware found

Unfortunatley in the worst and most common case however you
can typically crash your system with a page fault by trying to
free something which you cannot, and/or a NULL pointer
dereference [1].

The fix and issue using schedule_work() for asynchronous
runs is generalized in the following SmPL grammar patch,
when applied to next-20150505 only the firmware_class
code is affected. This grammar patch can and should further
be generalized to vet for for other kernel asynchronous
mechanisms.

@ calls_schedule_work @
type T;
T *priv_work;
identifier func, work_func;
identifier work;
identifier priv_name, name;
statement S;
expression gfp;
@@

 func(..., const char *name, ...)
 {
 	...
 	priv_work = kzalloc(sizeof(T), gfp);
 	...
-	priv_work->priv_name = name;
+	priv_work->priv_name = kstrdup_const(name, gfp);
	...
(... when any
 	if (...)
 	{
 		...
+ 		kfree_const(priv_work->priv_name);
 		kfree(priv_work);
		...
 	}
) ... when any
 	INIT_WORK(&priv_work->work, work_func);
 	...
 	schedule_work(&priv_work->work);
 	...
 }

@ the_work_func depends on calls_schedule_work @
type calls_schedule_work.T;
T *priv_work;
identifier calls_schedule_work.work_func;
identifier calls_schedule_work.priv_name;
identifier calls_schedule_work.work;
identifier some_work;
@@

 work_func(...)
 {
 	...
 	priv_work = container_of(some_work, T, work);
 	...
+	kfree_const(priv_work->priv_name);
 	kfree(priv_work);
 	...
 }

[0] https://github.com/mcgrof/fake-firmware-test.git
[1] The following kernel ring buffer splat:

firmware name: test_module_stuff.bin
firmware name:
firmware found
general protection fault: 0000 [#1] SMP
Modules linked in: test(O) <...etc-it-does-not-matter>
 drm sr_mod cdrom xhci_pci xhci_hcd rtsx_pci mfd_core video button sg
CPU: 3 PID: 87 Comm: kworker/3:2 Tainted: G           O    4.0.0-00010-g22b5bb0-dirty #176
Hardware name: LENOVO 20AW000LUS/20AW000LUS, BIOS GLET43WW (1.18 ) 12/04/2013
Workqueue: events request_firmware_work_func
task: ffff8800c7f8e290 ti: ffff8800c7f94000 task.ti: ffff8800c7f94000
RIP: 0010:[<ffffffff814a586c>]  [<ffffffff814a586c>] fw_free_buf+0xc/0x40
RSP: 0000:ffff8800c7f97d78  EFLAGS: 00010286
RAX: ffffffff81ae3700 RBX: ffffffff816d1181 RCX: 0000000000000006
RDX: 0001ee850ff68500 RSI: 0000000000000246 RDI: c35d5f415e415d41
RBP: ffff8800c7f97d88 R08: 000000000000000a R09: 0000000000000000
R10: 0000000000000358 R11: ffff8800c7f97a7e R12: ffff8800c7ec1e80
R13: ffff88021e2d4cc0 R14: ffff88021e2dff00 R15: 00000000000000c0
FS:  0000000000000000(0000) GS:ffff88021e2c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000034b8cd8 CR3: 000000021073c000 CR4: 00000000001407e0
Stack:
 ffffffff816d1181 ffff8800c7ec1e80 ffff8800c7f97da8 ffffffff814a58f8
 000000000000000a ffffffff816d1181 ffff8800c7f97dc8 ffffffffa047002c
 ffff88021e2dff00 ffff8802116ac1c0 ffff8800c7f97df8 ffffffff814a65fe
Call Trace:
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff814a58f8>] release_firmware+0x58/0x80
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffffa047002c>] test_mod_cb+0x2c/0x43 [test]
 [<ffffffff814a65fe>] request_firmware_work_func+0x5e/0x80
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff8108d23a>] process_one_work+0x14a/0x3f0
 [<ffffffff8108d911>] worker_thread+0x121/0x460
 [<ffffffff8108d7f0>] ? rescuer_thread+0x310/0x310
 [<ffffffff810928f9>] kthread+0xc9/0xe0
 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
 [<ffffffff816d52d8>] ret_from_fork+0x58/0x90
 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
Code: c7 c6 dd ad a3 81 48 c7 c7 20 97 ce 81 31 c0 e8 0b b2 ed ff e9 78 ff ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 54 53 <4c> 8b 67 38 48 89 fb 4c 89 e7 e8 85 f7 22 00 f0 83 2b 01 74 0f
RIP  [<ffffffff814a586c>] fw_free_buf+0xc/0x40
 RSP <ffff8800c7f97d78>
---[ end trace 4e62c56a58d0eac1 ]---
BUG: unable to handle kernel paging request at ffffffffffffffd8
IP: [<ffffffff81093ee0>] kthread_data+0x10/0x20
PGD 1c13067 PUD 1c15067 PMD 0
Oops: 0000 [#2] SMP
Modules linked in: test(O) <...etc-it-does-not-matter>
 drm sr_mod cdrom xhci_pci xhci_hcd rtsx_pci mfd_core video button sg
CPU: 3 PID: 87 Comm: kworker/3:2 Tainted: G      D    O    4.0.0-00010-g22b5bb0-dirty #176
Hardware name: LENOVO 20AW000LUS/20AW000LUS, BIOS GLET43WW (1.18 ) 12/04/2013
task: ffff8800c7f8e290 ti: ffff8800c7f94000 task.ti: ffff8800c7f94000
RIP: 0010:[<ffffffff81092ee0>]  [<ffffffff81092ee0>] kthread_data+0x10/0x20
RSP: 0018:ffff8800c7f97b18  EFLAGS: 00010096
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 000000000000000d
RDX: 0000000000000003 RSI: 0000000000000003 RDI: ffff8800c7f8e290
RBP: ffff8800c7f97b18 R08: 000000000000bc00 R09: 0000000000007e76
R10: 0000000000000001 R11: 000000000000002f R12: ffff8800c7f8e290
R13: 00000000000154c0 R14: 0000000000000003 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88021e2c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000028 CR3: 0000000210675000 CR4: 00000000001407e0
Stack:
 ffff8800c7f97b38 ffffffff8108dcd5 ffff8800c7f97b38 ffff88021e2d54c0
 ffff8800c7f97b88 ffffffff816d1500 ffff880213d42368 ffff8800c7f8e290
 ffff8800c7f97b88 ffff8800c7f97fd8 ffff8800c7f8e710 0000000000000246
Call Trace:
 [<ffffffff8108dcd5>] wq_worker_sleeping+0x15/0xa0
 [<ffffffff816d1500>] __schedule+0x6e0/0x940
 [<ffffffff816d1797>] schedule+0x37/0x90
 [<ffffffff810779bc>] do_exit+0x6bc/0xb40
 [<ffffffff8101898f>] oops_end+0x9f/0xe0
 [<ffffffff81018efb>] die+0x4b/0x70
 [<ffffffff81015622>] do_general_protection+0xe2/0x170
 [<ffffffff816d74e8>] general_protection+0x28/0x30
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff814a586c>] ? fw_free_buf+0xc/0x40
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff814a58f8>] release_firmware+0x58/0x80
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffffa047002c>] test_mod_cb+0x2c/0x43 [test]
 [<ffffffff814a65fe>] request_firmware_work_func+0x5e/0x80
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff8108d23a>] process_one_work+0x14a/0x3f0
 [<ffffffff8108d911>] worker_thread+0x121/0x460
 [<ffffffff8108d7f0>] ? rescuer_thread+0x310/0x310
 [<ffffffff810928f9>] kthread+0xc9/0xe0
 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
 [<ffffffff816d52d8>] ret_from_fork+0x58/0x90
 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
Code: 00 48 89 e5 5d 48 8b 40 c8 48 c1 e8 02 83 e0 01 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 87 30 05 00 00 55 48 89 e5 <48> 8b 40 d8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
RIP  [<ffffffff81092ee0>] kthread_data+0x10/0x20
 RSP <ffff8800c7f97b18>
CR2: ffffffffffffffd8
---[ end trace 4e62c56a58d0eac2 ]---
Fixing recursive fault but reboot is needed!

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Cc: stable@vger.kernel.org
Cc: cocci@systeme.lip6.fr
Generated-by: Coccinelle SmPL
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/base/firmware_class.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 6c5c9ed..2e85860 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1242,6 +1242,7 @@ static void request_firmware_work_func(struct work_struct *work)
 	put_device(fw_work->device); /* taken in request_firmware_nowait() */
 
 	module_put(fw_work->module);
+	kfree_const(fw_work->name);
 	kfree(fw_work);
 }
 
@@ -1281,7 +1282,7 @@ request_firmware_nowait(
 		return -ENOMEM;
 
 	fw_work->module = module;
-	fw_work->name = name;
+	fw_work->name = kstrdup_const(name, gfp);
 	fw_work->device = device;
 	fw_work->context = context;
 	fw_work->cont = cont;
@@ -1289,6 +1290,7 @@ request_firmware_nowait(
 		(uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
 
 	if (!try_module_get(module)) {
+		kfree_const(fw_work->name);
 		kfree(fw_work);
 		return -EFAULT;
 	}
-- 
2.3.2.209.gd67f9d5.dirty


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 04/12] firmware: fix possible use after free on name on asynchronous request

[Luis R. Rodriguez]

On Tue, May 05, 2015 at 05:44:22PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> Asynchronous firmware loading copies the pointer to the
> name passed as an argument only to be scheduled later and
> used. This behaviour works well for synchronous calling
> but in asynchronous mode there's a chance the caller could
> immediately free the passed string after making the
> asynchronous call. This could trigger a use after free
> having the kernel look on disk for arbitrary file names.

<-- snip -->

> Unfortunatley in the worst and most common case however you
> can typically crash your system with a page fault by trying to
> free something which you cannot, and/or a NULL pointer
> dereference [1].

I've found a few more bugs in this code that should be
stable fixes. Since the fixes are all related there is
an alternative approach to the problem here which would
require us to just deal with PATH_MAX a few times in code
for firmware requests. Although that does increase the
allocation required by a few KB I think the simplicity
is worth it. So if this patch has not yet been applied
I will send out a new series of fixes addressing name
issues through an alternative approach and implementation
preferences so please yield applying this yet, if it has
already been applied / submitted upstream let me know.

  Luis

Re: [wireless-regdb] [PATCH v1 04/12] firmware: fix possible use after free on name on asynchronous request

[Luis R. Rodriguez]

On Tue, May 05, 2015 at 05:44:22PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
> Asynchronous firmware loading copies the pointer to the
> name passed as an argument only to be scheduled later and
> used. This behaviour works well for synchronous calling
> but in asynchronous mode there's a chance the caller could
> immediately free the passed string after making the
> asynchronous call. This could trigger a use after free
> having the kernel look on disk for arbitrary file names.

<-- snip -->

> Unfortunatley in the worst and most common case however you
> can typically crash your system with a page fault by trying to
> free something which you cannot, and/or a NULL pointer
> dereference [1].

I've found a few more bugs in this code that should be
stable fixes. Since the fixes are all related there is
an alternative approach to the problem here which would
require us to just deal with PATH_MAX a few times in code
for firmware requests. Although that does increase the
allocation required by a few KB I think the simplicity
is worth it. So if this patch has not yet been applied
I will send out a new series of fixes addressing name
issues through an alternative approach and implementation
preferences so please yield applying this yet, if it has
already been applied / submitted upstream let me know.

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

[RFC v1 05/12] firmware: add firmware signature checking support

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Systems that have module signing currently enabled may
wish to extend vetting of firmware passed to the kernel
as well. We can re-use most of the code for module signing
for firmware signature verification and signing. This will
also later enable re-use of this same code for subsystems
that wish to provide their own cryptographic verification
mechanisms on userspace data needed.

As with module signing, we do a very simple search for a
particular string appended to the firmware. There's both a
config option and a boot parameter which control whether we
accept or fail with unsigned firmware and firmware that are
signed with an unknown key.

If firmware signing is enabled, the kernel will be tainted
if a firmware is loaded that is unsigned or has a signature
for which we don't have the key.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/base/Kconfig                               | 16 +++++++
 drivers/base/firmware_class.c                      | 52 +++++++++++++++++++++-
 include/linux/firmware.h                           |  1 +
 .../sysdata-internal.h => include/linux/sysdata.h  |  1 +
 kernel/module.c                                    |  2 +-
 kernel/sysdata_signing.c                           |  3 +-
 kernel/system_keyring.c                            |  2 +-
 scripts/sign-file                                  | 20 ++++++---
 8 files changed, 87 insertions(+), 10 deletions(-)
 rename kernel/sysdata-internal.h => include/linux/sysdata.h (87%)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 98504ec..a831772 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -85,6 +85,22 @@ config FW_LOADER
 	  require userspace firmware loading support, but a module built
 	  out-of-tree does.
 
+config FIRMWARE_SIG
+	bool "Firmware signature verification"
+	depends on FW_LOADER
+	select SYSDATA_SIG
+	help
+	  Check firmware files for valid signatures upon load: the signature
+	  is simply appended to the firmware. For more information see
+	  Documentation/firmware-signing.txt.
+
+config FIRMWARE_SIG_FORCE
+	bool "Require all firmware to be validly signed"
+	depends on FIRMWARE_SIG
+	help
+	  Reject unsigned files or signed files for which we don't have a
+	  key.  Without this, such firmware files will simply taint the kernel.
+
 config FIRMWARE_IN_KERNEL
 	bool "Include in-kernel firmware blobs in kernel binary"
 	depends on FW_LOADER
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 2e85860..65fcf2d 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -29,6 +29,7 @@
 #include <linux/syscore_ops.h>
 #include <linux/reboot.h>
 #include <linux/security.h>
+#include <linux/sysdata.h>
 
 #include <generated/utsrelease.h>
 
@@ -38,6 +39,11 @@ MODULE_AUTHOR("Manuel Estrada Sainz");
 MODULE_DESCRIPTION("Multi purpose firmware loading support");
 MODULE_LICENSE("GPL");
 
+static bool fw_sig_enforce = IS_ENABLED(CONFIG_FIRMWARE_SIG_FORCE);
+#ifndef CONFIG_FIRMWARE_SIG_FORCE
+module_param(fw_sig_enforce, bool_enable_only, 0644);
+#endif /* !CONFIG_FIRMWARE_SIG_FORCE */
+
 /* Builtin firmware support */
 
 #ifdef CONFIG_FW_LOADER
@@ -142,6 +148,7 @@ struct firmware_buf {
 	unsigned long status;
 	void *data;
 	size_t size;
+	bool sig_ok;
 #ifdef CONFIG_FW_LOADER_USER_HELPER
 	bool is_paged_buf;
 	bool need_uevent;
@@ -378,12 +385,50 @@ static void fw_set_page_data(struct firmware_buf *buf, struct firmware *fw)
 #endif
 	fw->size = buf->size;
 	fw->data = buf->data;
+	fw->sig_ok = buf->sig_ok;
 
-	pr_debug("%s: fw-%s buf=%p data=%p size=%u\n",
+	pr_debug("%s: fw-%s buf=%p data=%p size=%u sig_ok=%d\n",
 		 __func__, buf->fw_id, buf, buf->data,
-		 (unsigned int)buf->size);
+		 (unsigned int)buf->size, buf->sig_ok);
 }
 
+#ifdef CONFIG_FIRMWARE_SIG
+static int firmware_sig_check(struct firmware *fw)
+{
+	int err = -ENOKEY;
+	const unsigned long markerlen = sizeof(SYSDATA_SIG_STRING) - 1;
+	struct firmware_buf *buf = fw->priv;
+	const void *data = buf->data;
+
+	if (buf->size > markerlen &&
+	    memcmp(data + buf->size - markerlen, SYSDATA_SIG_STRING, markerlen) == 0) {
+		/* We truncate the firmware to discard the signature */
+		buf->size -= markerlen;
+		err = sysdata_verify_sig(data, &buf->size);
+	}
+
+	if (!err) {
+		buf->sig_ok = true;
+		fw_set_page_data(buf, fw);
+		return 0;
+	}
+
+	/* Not having a signature is only an error if we're strict. */
+	if (err == -ENOKEY && !fw_sig_enforce)
+		err = 0;
+
+	fw_set_page_data(buf, fw);
+
+	return err;
+}
+#else /* !CONFIG_FIRMWARE_SIG */
+static int firmware_sig_check(struct firmware *fw)
+{
+	return 0;
+}
+#endif /* !CONFIG_MODULE_SIG */
+
+
 #ifdef CONFIG_PM_SLEEP
 static void fw_name_devm_release(struct device *dev, void *res)
 {
@@ -1137,6 +1182,9 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
 	usermodehelper_read_unlock();
 
  out:
+	if (ret >= 0)
+		ret = firmware_sig_check(fw);
+
 	if (ret < 0) {
 		release_firmware(fw);
 		fw = NULL;
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index 5c41c5e..d814102 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -11,6 +11,7 @@
 struct firmware {
 	size_t size;
 	const u8 *data;
+	bool sig_ok;
 	struct page **pages;
 
 	/* firmware loader private fields */
diff --git a/kernel/sysdata-internal.h b/include/linux/sysdata.h
similarity index 87%
rename from kernel/sysdata-internal.h
rename to include/linux/sysdata.h
index 0aa573e..b40b873 100644
--- a/kernel/sysdata-internal.h
+++ b/include/linux/sysdata.h
@@ -10,3 +10,4 @@
  */
 
 extern int sysdata_verify_sig(const void *data, unsigned long *_len);
+#define SYSDATA_SIG_STRING "~System data signature appended~\n"
diff --git a/kernel/module.c b/kernel/module.c
index eb61c10..1dda9749 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -59,8 +59,8 @@
 #include <linux/jump_label.h>
 #include <linux/pfn.h>
 #include <linux/bsearch.h>
+#include <linux/sysdata.h>
 #include <uapi/linux/module.h>
-#include "sysdata-internal.h"
 
 #define CREATE_TRACE_POINTS
 #include <trace/events/module.h>
diff --git a/kernel/sysdata_signing.c b/kernel/sysdata_signing.c
index 8ba09aa..8179f8e 100644
--- a/kernel/sysdata_signing.c
+++ b/kernel/sysdata_signing.c
@@ -11,11 +11,11 @@
 
 #include <linux/kernel.h>
 #include <linux/err.h>
+#include <linux/sysdata.h>
 #include <crypto/public_key.h>
 #include <crypto/hash.h>
 #include <keys/asymmetric-type.h>
 #include <keys/system_keyring.h>
-#include "sysdata-internal.h"
 
 /*
  * System Data signature information block.
@@ -248,3 +248,4 @@ error_put_key:
 	pr_devel("<==%s() = %d\n", __func__, ret);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(sysdata_verify_sig);
diff --git a/kernel/system_keyring.c b/kernel/system_keyring.c
index 1eb0c86..a0b8653 100644
--- a/kernel/system_keyring.c
+++ b/kernel/system_keyring.c
@@ -14,9 +14,9 @@
 #include <linux/sched.h>
 #include <linux/cred.h>
 #include <linux/err.h>
+#include <linux/sysdata.h>
 #include <keys/asymmetric-type.h>
 #include <keys/system_keyring.h>
-#include "sysdata-internal.h"
 
 struct key *system_trusted_keyring;
 EXPORT_SYMBOL_GPL(system_trusted_keyring);
diff --git a/scripts/sign-file b/scripts/sign-file
index 3906ee1..dd7ef57 100755
--- a/scripts/sign-file
+++ b/scripts/sign-file
@@ -4,20 +4,24 @@
 #
 
 my $USAGE =
-"Usage: scripts/sign-file [-v] <hash algo> <key> <x509> <module> [<dest>]\n" .
-"       scripts/sign-file [-v] -s <raw sig> <hash algo> <x509> <module> [<dest>]\n";
+"Usage: scripts/sign-file [-v] [-d] <hash algo> <key> <x509> <module> [<dest>]\n" .
+"       scripts/sign-file [-v] [-d] -s <raw sig> <hash algo> <x509> <module> [<dest>]\n";
 
 use strict;
 use FileHandle;
 use IPC::Open2;
 use Getopt::Std;
 
+my $module_magic_number = "~Module signature appended~\n";
+my $system_magic_number = "~System data signature appended~\n";
+
 my %opts;
-getopts('vs:', \%opts) or die $USAGE;
+getopts('vds:', \%opts) or die $USAGE;
 my $verbose = $opts{'v'};
+my $system_data = $opts{'d'};
 my $signature_file = $opts{'s'};
 
-die $USAGE if ($#ARGV > 4);
+die $USAGE if ($#ARGV > 5);
 die $USAGE if (!$signature_file && $#ARGV < 3 || $signature_file && $#ARGV < 2);
 
 my $dgst = shift @ARGV;
@@ -385,7 +389,13 @@ $signature = pack("n", length($signature)) . $signature,
 #
 my $unsigned_module = read_file($module);
 
-my $magic_number = "~Module signature appended~\n";
+my $magic_number = "";
+
+if ($system_data) {
+	$magic_number = $system_magic_number;
+} else {
+	$magic_number = $module_magic_number;
+}
 
 my $info = pack("CCCCCxxxN",
 		$algo, $hash, $id_type,
-- 
2.3.2.209.gd67f9d5.dirty

[wireless-regdb] [RFC v1 05/12] firmware: add firmware signature checking support

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Systems that have module signing currently enabled may
wish to extend vetting of firmware passed to the kernel
as well. We can re-use most of the code for module signing
for firmware signature verification and signing. This will
also later enable re-use of this same code for subsystems
that wish to provide their own cryptographic verification
mechanisms on userspace data needed.

As with module signing, we do a very simple search for a
particular string appended to the firmware. There's both a
config option and a boot parameter which control whether we
accept or fail with unsigned firmware and firmware that are
signed with an unknown key.

If firmware signing is enabled, the kernel will be tainted
if a firmware is loaded that is unsigned or has a signature
for which we don't have the key.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/base/Kconfig                               | 16 +++++++
 drivers/base/firmware_class.c                      | 52 +++++++++++++++++++++-
 include/linux/firmware.h                           |  1 +
 .../sysdata-internal.h => include/linux/sysdata.h  |  1 +
 kernel/module.c                                    |  2 +-
 kernel/sysdata_signing.c                           |  3 +-
 kernel/system_keyring.c                            |  2 +-
 scripts/sign-file                                  | 20 ++++++---
 8 files changed, 87 insertions(+), 10 deletions(-)
 rename kernel/sysdata-internal.h => include/linux/sysdata.h (87%)

diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 98504ec..a831772 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -85,6 +85,22 @@ config FW_LOADER
 	  require userspace firmware loading support, but a module built
 	  out-of-tree does.
 
+config FIRMWARE_SIG
+	bool "Firmware signature verification"
+	depends on FW_LOADER
+	select SYSDATA_SIG
+	help
+	  Check firmware files for valid signatures upon load: the signature
+	  is simply appended to the firmware. For more information see
+	  Documentation/firmware-signing.txt.
+
+config FIRMWARE_SIG_FORCE
+	bool "Require all firmware to be validly signed"
+	depends on FIRMWARE_SIG
+	help
+	  Reject unsigned files or signed files for which we don't have a
+	  key.  Without this, such firmware files will simply taint the kernel.
+
 config FIRMWARE_IN_KERNEL
 	bool "Include in-kernel firmware blobs in kernel binary"
 	depends on FW_LOADER
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 2e85860..65fcf2d 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -29,6 +29,7 @@
 #include <linux/syscore_ops.h>
 #include <linux/reboot.h>
 #include <linux/security.h>
+#include <linux/sysdata.h>
 
 #include <generated/utsrelease.h>
 
@@ -38,6 +39,11 @@ MODULE_AUTHOR("Manuel Estrada Sainz");
 MODULE_DESCRIPTION("Multi purpose firmware loading support");
 MODULE_LICENSE("GPL");
 
+static bool fw_sig_enforce = IS_ENABLED(CONFIG_FIRMWARE_SIG_FORCE);
+#ifndef CONFIG_FIRMWARE_SIG_FORCE
+module_param(fw_sig_enforce, bool_enable_only, 0644);
+#endif /* !CONFIG_FIRMWARE_SIG_FORCE */
+
 /* Builtin firmware support */
 
 #ifdef CONFIG_FW_LOADER
@@ -142,6 +148,7 @@ struct firmware_buf {
 	unsigned long status;
 	void *data;
 	size_t size;
+	bool sig_ok;
 #ifdef CONFIG_FW_LOADER_USER_HELPER
 	bool is_paged_buf;
 	bool need_uevent;
@@ -378,12 +385,50 @@ static void fw_set_page_data(struct firmware_buf *buf, struct firmware *fw)
 #endif
 	fw->size = buf->size;
 	fw->data = buf->data;
+	fw->sig_ok = buf->sig_ok;
 
-	pr_debug("%s: fw-%s buf=%p data=%p size=%u\n",
+	pr_debug("%s: fw-%s buf=%p data=%p size=%u sig_ok=%d\n",
 		 __func__, buf->fw_id, buf, buf->data,
-		 (unsigned int)buf->size);
+		 (unsigned int)buf->size, buf->sig_ok);
 }
 
+#ifdef CONFIG_FIRMWARE_SIG
+static int firmware_sig_check(struct firmware *fw)
+{
+	int err = -ENOKEY;
+	const unsigned long markerlen = sizeof(SYSDATA_SIG_STRING) - 1;
+	struct firmware_buf *buf = fw->priv;
+	const void *data = buf->data;
+
+	if (buf->size > markerlen &&
+	    memcmp(data + buf->size - markerlen, SYSDATA_SIG_STRING, markerlen) == 0) {
+		/* We truncate the firmware to discard the signature */
+		buf->size -= markerlen;
+		err = sysdata_verify_sig(data, &buf->size);
+	}
+
+	if (!err) {
+		buf->sig_ok = true;
+		fw_set_page_data(buf, fw);
+		return 0;
+	}
+
+	/* Not having a signature is only an error if we're strict. */
+	if (err == -ENOKEY && !fw_sig_enforce)
+		err = 0;
+
+	fw_set_page_data(buf, fw);
+
+	return err;
+}
+#else /* !CONFIG_FIRMWARE_SIG */
+static int firmware_sig_check(struct firmware *fw)
+{
+	return 0;
+}
+#endif /* !CONFIG_MODULE_SIG */
+
+
 #ifdef CONFIG_PM_SLEEP
 static void fw_name_devm_release(struct device *dev, void *res)
 {
@@ -1137,6 +1182,9 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
 	usermodehelper_read_unlock();
 
  out:
+	if (ret >= 0)
+		ret = firmware_sig_check(fw);
+
 	if (ret < 0) {
 		release_firmware(fw);
 		fw = NULL;
diff --git a/include/linux/firmware.h b/include/linux/firmware.h
index 5c41c5e..d814102 100644
--- a/include/linux/firmware.h
+++ b/include/linux/firmware.h
@@ -11,6 +11,7 @@
 struct firmware {
 	size_t size;
 	const u8 *data;
+	bool sig_ok;
 	struct page **pages;
 
 	/* firmware loader private fields */
diff --git a/kernel/sysdata-internal.h b/include/linux/sysdata.h
similarity index 87%
rename from kernel/sysdata-internal.h
rename to include/linux/sysdata.h
index 0aa573e..b40b873 100644
--- a/kernel/sysdata-internal.h
+++ b/include/linux/sysdata.h
@@ -10,3 +10,4 @@
  */
 
 extern int sysdata_verify_sig(const void *data, unsigned long *_len);
+#define SYSDATA_SIG_STRING "~System data signature appended~\n"
diff --git a/kernel/module.c b/kernel/module.c
index eb61c10..1dda9749 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -59,8 +59,8 @@
 #include <linux/jump_label.h>
 #include <linux/pfn.h>
 #include <linux/bsearch.h>
+#include <linux/sysdata.h>
 #include <uapi/linux/module.h>
-#include "sysdata-internal.h"
 
 #define CREATE_TRACE_POINTS
 #include <trace/events/module.h>
diff --git a/kernel/sysdata_signing.c b/kernel/sysdata_signing.c
index 8ba09aa..8179f8e 100644
--- a/kernel/sysdata_signing.c
+++ b/kernel/sysdata_signing.c
@@ -11,11 +11,11 @@
 
 #include <linux/kernel.h>
 #include <linux/err.h>
+#include <linux/sysdata.h>
 #include <crypto/public_key.h>
 #include <crypto/hash.h>
 #include <keys/asymmetric-type.h>
 #include <keys/system_keyring.h>
-#include "sysdata-internal.h"
 
 /*
  * System Data signature information block.
@@ -248,3 +248,4 @@ error_put_key:
 	pr_devel("<==%s() = %d\n", __func__, ret);
 	return ret;
 }
+EXPORT_SYMBOL_GPL(sysdata_verify_sig);
diff --git a/kernel/system_keyring.c b/kernel/system_keyring.c
index 1eb0c86..a0b8653 100644
--- a/kernel/system_keyring.c
+++ b/kernel/system_keyring.c
@@ -14,9 +14,9 @@
 #include <linux/sched.h>
 #include <linux/cred.h>
 #include <linux/err.h>
+#include <linux/sysdata.h>
 #include <keys/asymmetric-type.h>
 #include <keys/system_keyring.h>
-#include "sysdata-internal.h"
 
 struct key *system_trusted_keyring;
 EXPORT_SYMBOL_GPL(system_trusted_keyring);
diff --git a/scripts/sign-file b/scripts/sign-file
index 3906ee1..dd7ef57 100755
--- a/scripts/sign-file
+++ b/scripts/sign-file
@@ -4,20 +4,24 @@
 #
 
 my $USAGE =
-"Usage: scripts/sign-file [-v] <hash algo> <key> <x509> <module> [<dest>]\n" .
-"       scripts/sign-file [-v] -s <raw sig> <hash algo> <x509> <module> [<dest>]\n";
+"Usage: scripts/sign-file [-v] [-d] <hash algo> <key> <x509> <module> [<dest>]\n" .
+"       scripts/sign-file [-v] [-d] -s <raw sig> <hash algo> <x509> <module> [<dest>]\n";
 
 use strict;
 use FileHandle;
 use IPC::Open2;
 use Getopt::Std;
 
+my $module_magic_number = "~Module signature appended~\n";
+my $system_magic_number = "~System data signature appended~\n";
+
 my %opts;
-getopts('vs:', \%opts) or die $USAGE;
+getopts('vds:', \%opts) or die $USAGE;
 my $verbose = $opts{'v'};
+my $system_data = $opts{'d'};
 my $signature_file = $opts{'s'};
 
-die $USAGE if ($#ARGV > 4);
+die $USAGE if ($#ARGV > 5);
 die $USAGE if (!$signature_file && $#ARGV < 3 || $signature_file && $#ARGV < 2);
 
 my $dgst = shift @ARGV;
@@ -385,7 +389,13 @@ $signature = pack("n", length($signature)) . $signature,
 #
 my $unsigned_module = read_file($module);
 
-my $magic_number = "~Module signature appended~\n";
+my $magic_number = "";
+
+if ($system_data) {
+	$magic_number = $system_magic_number;
+} else {
+	$magic_number = $module_magic_number;
+}
 
 my $info = pack("CCCCCxxxN",
 		$algo, $hash, $id_type,
-- 
2.3.2.209.gd67f9d5.dirty


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

[RFC v1 06/12] firmware: generalize "firmware" as "system data" helpers

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Historically firmware_class code was added to help
get device driver firmware binaries but these days
request_firmware*() helpers are being repurposed for
general system data needed by the kernel.

Annotate this before we extend firmare_class more,
as this is expected. We want to generalize the code
as much as possible.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/base/firmware_class.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 65fcf2d..55091b4 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -346,7 +346,7 @@ static int fw_get_filesystem_firmware(struct device *device,
 		rc = fw_read_file_contents(file, buf);
 		fput(file);
 		if (rc)
-			dev_warn(device, "firmware, attempted to load %s, but failed with error %d\n",
+			dev_warn(device, "system data, attempted to load %s, but failed with error %d\n",
 				path, rc);
 		else
 			break;
@@ -354,7 +354,7 @@ static int fw_get_filesystem_firmware(struct device *device,
 	__putname(path);
 
 	if (!rc) {
-		dev_dbg(device, "firmware: direct-loading firmware %s\n",
+		dev_dbg(device, "system data: direct-loading firmware %s\n",
 			buf->fw_id);
 		mutex_lock(&fw_lock);
 		set_bit(FW_STATUS_DONE, &buf->status);
@@ -1063,7 +1063,7 @@ _request_firmware_prepare(struct firmware **firmware_p, const char *name,
 	}
 
 	if (fw_get_builtin_firmware(firmware, name)) {
-		dev_dbg(device, "firmware: using built-in firmware %s\n", name);
+		dev_dbg(device, "system data: using built-in system data%s\n", name);
 		return 0; /* assigned */
 	}
 
-- 
2.3.2.209.gd67f9d5.dirty

[wireless-regdb] [RFC v1 06/12] firmware: generalize "firmware" as "system data" helpers

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Historically firmware_class code was added to help
get device driver firmware binaries but these days
request_firmware*() helpers are being repurposed for
general system data needed by the kernel.

Annotate this before we extend firmare_class more,
as this is expected. We want to generalize the code
as much as possible.

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/base/firmware_class.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 65fcf2d..55091b4 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -346,7 +346,7 @@ static int fw_get_filesystem_firmware(struct device *device,
 		rc = fw_read_file_contents(file, buf);
 		fput(file);
 		if (rc)
-			dev_warn(device, "firmware, attempted to load %s, but failed with error %d\n",
+			dev_warn(device, "system data, attempted to load %s, but failed with error %d\n",
 				path, rc);
 		else
 			break;
@@ -354,7 +354,7 @@ static int fw_get_filesystem_firmware(struct device *device,
 	__putname(path);
 
 	if (!rc) {
-		dev_dbg(device, "firmware: direct-loading firmware %s\n",
+		dev_dbg(device, "system data: direct-loading firmware %s\n",
 			buf->fw_id);
 		mutex_lock(&fw_lock);
 		set_bit(FW_STATUS_DONE, &buf->status);
@@ -1063,7 +1063,7 @@ _request_firmware_prepare(struct firmware **firmware_p, const char *name,
 	}
 
 	if (fw_get_builtin_firmware(firmware, name)) {
-		dev_dbg(device, "firmware: using built-in firmware %s\n", name);
+		dev_dbg(device, "system data: using built-in system data%s\n", name);
 		return 0; /* assigned */
 	}
 
-- 
2.3.2.209.gd67f9d5.dirty


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

[RFC v1 07/12] firmware: add generic system data helpers with signature support

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

The Linux kernel has use cases for non-firmware file requests
from the filesystem. Some drivers, for instance the p54 driver,
uses the request_firmware() API to upload default EEPROM overrides.
Likewise, since the kernel already has cryptographic digital
signature verification support subsystems which have userspace
agents which historically have required cyptographic digital file
verification checks can replace those agents by using the kernel's
own digital verification checks on files requested from userspace.

At least for 802.11 and CRDA's [0] case for example, this is required
since CRDA has historically always had enabled digital signature
suppport on most distributions for the regulatory.bin file used to
store the 802.11 regulatory database. Providing an in-kernel replacement
should meet these same requirements unless of course distributions
start enabling digital firmware signature verification for all
required firmware. The keys for the signing regulatory data has
also been historically different than distribution's own keys
used for module signing.

There are a few motivations to replace userespace agents with these
crypto optional requirements:

  * there is a need for userspace / kernel sync up

  * the regulatory database ASCII format requires a binary
    converter and its format also needs to kept in sync
    for users that wish to have the regulatory database built
    into the kernel. Currently the ASCII db.txt file is parsed
    on the kernel through a fragile awk script. Keeping things
    in sync as the schema grows proves complex.

  * the kernel already has firmware-built-in support (see
    EXTRA_FIRMWARE) which can replace our own ASCII to db
    parser by letting us keep the firmware as binary in the
    kernel

The Linux integrity subsystem (IMA) provides a means [1] to enable
appraisal of files in userspace, this can also be used, however CRDA
has historically been used to vet for authenticity and integrity of
the regulatory database used for in-kernel 802.11 functionality.
Use of IMA is optional, support for digital signatures for files
used in-kernel can be have different subsystem specific requirements.

There's a few issues with extending the exisitng APIs however with
dynamic and custom cryptographic support. We keep pushing firmware
APIs by extending the number of arguments needed as requirements
grow or by adding new flags used internally for the different types
of new APIs exported. Behaviour can vary depending on whether a
usermode helper alternative is required, and we provide two types of
modes of operation: synchronous and asynchronous. Instead of
extending each of all these APIs with private flags this provides a
slim down implementation of what is required to get system data from
userspace to callers, without usermode helper alternative support
ripped out and by allowing the APIs to be extensible over time
depending on whether or not they are synchronous or asynchronous.

For now this initial implementation only provides an optional
requirement for subsystems to be able to override digital
signature support, for instance, even though firmware signing
might not have been enabled this lets distributions which have
had digital signature requirements for specifici files to upkeep
that tradition.

-- Consider this patch is incomplete as it still does not
   allow custom key specification, if distributions decided
   to only allow signed firmware we might be able to live with
   having distributions sign their own firmware and just stuff
   reguatory.bin into /lib/firmware. Distributions might wish
   to also make this call on their own as well.

   This patch is intended to help bring discussion about what
   we wish to do for the above requirements and also to help
   plan and coordinate future extensions to the firmware module
   and its APIs.

[0] https://wireless.wiki.kernel.org/en/developers/regulatory/crda
[1] http://sourceforge.net/p/linux-ima/wiki/Home/

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/base/firmware_class.c | 256 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/sysdata.h       | 189 ++++++++++++++++++++++++++++++-
 2 files changed, 444 insertions(+), 1 deletion(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 55091b4..b46472b 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -39,6 +39,13 @@ MODULE_AUTHOR("Manuel Estrada Sainz");
 MODULE_DESCRIPTION("Multi purpose firmware loading support");
 MODULE_LICENSE("GPL");
 
+/* Should be a hot path as its the default */
+static const struct sysdata_file_sync_reqs __read_mostly dfl_sync_reqs = {
+	.mode = SYNCDATA_SYNC,
+	.module = THIS_MODULE,
+	.gfp = GFP_KERNEL,
+};
+
 static bool fw_sig_enforce = IS_ENABLED(CONFIG_FIRMWARE_SIG_FORCE);
 #ifndef CONFIG_FIRMWARE_SIG_FORCE
 module_param(fw_sig_enforce, bool_enable_only, 0644);
@@ -1266,6 +1273,179 @@ void release_firmware(const struct firmware *fw)
 }
 EXPORT_SYMBOL(release_firmware);
 
+static void sysdata_file_update(struct sysdata_file *sysdata)
+{
+	struct firmware *fw;
+	struct firmware_buf *buf;
+
+	if (!sysdata || !sysdata->priv)
+		return;
+
+	fw = sysdata->priv;
+	if (!fw->priv)
+		return;
+
+	buf = fw->priv;
+
+	sysdata->size = buf->size;
+	sysdata->data = buf->data;
+	sysdata->sig_ok = buf->sig_ok;
+
+	pr_debug("%s: fw-%s buf=%p data=%p size=%u sig_ok=%d\n",
+		 __func__, buf->fw_id, buf, buf->data,
+		 (unsigned int)buf->size, buf->sig_ok);
+}
+
+#ifdef CONFIG_FIRMWARE_SIG_FORCE
+static int sysdata_file_sig_check(const struct sysdata_file_desc *desc,
+				  struct firmware *fw)
+{
+	return firmware_sig_check(fw);
+}
+#else
+static int sysdata_file_sig_check(const struct sysdata_file_desc *desc,
+				  struct firmware *fw)
+{
+	int ret;
+
+	ret = firmware_sig_check(fw);
+	if (ret && !desc->signature_required)
+		ret = 0;
+
+	return ret;
+}
+#endif
+
+/* prepare firmware and firmware_buf structs;
+ * return 0 if a firmware is already assigned, 1 if need to load one,
+ * or a negative error code
+ */
+static int
+_request_sysdata_prepare(struct sysdata_file **sysdata_p, const char *name,
+			  struct device *device)
+{
+	struct sysdata_file *sysdata;
+	struct firmware *fw;
+	int ret;
+
+	*sysdata_p = sysdata = kzalloc(sizeof(*sysdata), GFP_KERNEL);
+	if (!sysdata) {
+		dev_err(device, "%s: kmalloc(struct sysdata) failed\n",
+			__func__);
+		return -ENOMEM;
+	}
+
+	ret = _request_firmware_prepare(&fw, name, device);
+	if (ret >= 0)
+		sysdata->priv = fw;
+
+	return ret;
+}
+
+/**
+ * release_sysdata_file: - release the resource associated with the sysdata file
+ * @sysdata_file: sysdata resource to release
+ **/
+void release_sysdata_file(const struct sysdata_file *sysdata)
+{
+	struct firmware *fw;
+
+	if (sysdata) {
+		if (sysdata->priv) {
+			fw = sysdata->priv;
+			release_firmware(fw);
+		}
+	}
+	kfree(sysdata);
+}
+EXPORT_SYMBOL_GPL(release_sysdata_file);
+
+static int _sysdata_file_request(const struct sysdata_file **sysdata_p,
+				 const char *name,
+				 const struct sysdata_file_desc *desc,
+				 struct device *device)
+{
+	struct sysdata_file *sysdata;
+	struct firmware *fw = NULL;
+	int ret;
+
+	if (!sysdata_p)
+		return -EINVAL;
+
+	if (!desc)
+		return -EINVAL;
+
+	if (!name || name[0] == '\0')
+		return -EINVAL;
+
+	ret = _request_sysdata_prepare(&sysdata, name, device);
+	if (ret <= 0) /* error or already assigned */
+		goto out;
+
+	fw = sysdata->priv;
+
+	ret = fw_get_filesystem_firmware(device, fw->priv);
+	if (ret && !desc->optional)
+		pr_err("Direct system data load for %s failed with error %d\n",
+		       name, ret);
+
+	if (!ret)
+		ret = assign_firmware_buf(fw, device, FW_OPT_UEVENT);
+
+ out:
+	if (ret >= 0)
+		ret = sysdata_file_sig_check(desc, fw);
+
+	if (ret < 0) {
+		release_sysdata_file(sysdata);
+		sysdata = NULL;
+	}
+
+	sysdata_file_update(sysdata);
+
+	*sysdata_p = sysdata;
+
+	return ret;
+}
+
+int sysdata_file_request(const char *name,
+			 const struct sysdata_file_desc *desc,
+			 struct device *device)
+{
+	const struct sysdata_file *sysdata;
+	const struct sysdata_file_sync_reqs *sync_reqs;
+	int ret;
+
+	if (!device || !desc || !name)
+		return -EINVAL;
+
+	/*
+	 * XXX: This Follows old behaviour which pegs onto *this* module,
+	 * but if we wanted to, if we knew all callers had
+	 * a valid THIS_MODULE, we'd peg this into their own
+	 * module instead.
+	 */
+	sync_reqs = &dfl_sync_reqs;
+
+	if (sync_reqs->mode != SYNCDATA_SYNC)
+		return -EINVAL;
+
+	__module_get(sync_reqs->module);
+	get_device(device);
+
+	ret = _sysdata_file_request(&sysdata, name, desc, device);
+	if (ret && desc->optional)
+		ret = desc_sync_opt_call_cb(desc);
+	else
+		ret = desc_sync_found_call_cb(desc, sysdata);
+
+	put_device(device);
+	module_put(sync_reqs->module);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(sysdata_file_request);
+
 /* Async support */
 struct firmware_work {
 	struct work_struct work;
@@ -1350,6 +1530,82 @@ request_firmware_nowait(
 }
 EXPORT_SYMBOL(request_firmware_nowait);
 
+struct sysdata_file_work {
+	struct work_struct work;
+	const char *name;
+	struct sysdata_file_desc desc;
+	struct device *device;
+};
+
+static void request_sysdata_file_work_func(struct work_struct *work)
+{
+	struct sysdata_file_work *sys_work;
+	const struct sysdata_file_desc *desc;
+	const struct sysdata_file_sync_reqs *sync_reqs;
+	const struct sysdata_file *sysdata;
+	int ret;
+
+	sys_work = container_of(work, struct sysdata_file_work, work);
+	desc = &sys_work->desc;
+	sync_reqs = &desc->sync_reqs;
+
+	ret = _sysdata_file_request(&sysdata, sys_work->name,
+				    desc, sys_work->device);
+	if (ret && desc->optional)
+		desc_async_opt_call_cb(desc);
+	else
+		desc_async_found_call_cb(sysdata, desc);
+
+	put_device(sys_work->device);
+	module_put(sync_reqs->module);
+
+	kfree_const(sys_work->name);
+	kfree(sys_work);
+}
+
+int sysdata_file_request_async(const char *name,
+			       const struct sysdata_file_desc *desc,
+			       struct device *device)
+{
+	struct sysdata_file_work *sys_work;
+	const struct sysdata_file_sync_reqs *sync_reqs;
+
+	if (!device || !desc || !name)
+		return -EINVAL;
+
+	if (desc->sync_reqs.mode != SYNCDATA_ASYNC)
+		return -EINVAL;
+
+	if (!desc_async_found_cb(desc))
+		return -EINVAL;
+
+	sync_reqs = &desc->sync_reqs;
+
+	if (!sync_reqs->module)
+		return -EINVAL;
+
+	sys_work = kzalloc(sizeof(struct sysdata_file_work), sync_reqs->gfp);
+	if (!sys_work)
+		return -ENOMEM;
+
+	sys_work->desc = *desc;
+	sys_work->device = device;
+	sys_work->name = kstrdup_const(name, sync_reqs->gfp);
+
+	if (!try_module_get(sync_reqs->module)) {
+		kfree_const(sys_work->name);
+		kfree(sys_work);
+		return -EFAULT;
+	}
+
+	get_device(sys_work->device);
+	INIT_WORK(&sys_work->work, request_sysdata_file_work_func);
+	schedule_work(&sys_work->work);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(sysdata_file_request_async);
+
 #ifdef CONFIG_PM_SLEEP
 static ASYNC_DOMAIN_EXCLUSIVE(fw_cache_domain);
 
diff --git a/include/linux/sysdata.h b/include/linux/sysdata.h
index b40b873..b37c39d 100644
--- a/include/linux/sysdata.h
+++ b/include/linux/sysdata.h
@@ -1,6 +1,17 @@
-/* System Data internals
+#ifndef _LINUX_SYSDATA_H
+#define _LINUX_SYSDATA_H
+
+#include <linux/types.h>
+#include <linux/compiler.h>
+#include <linux/gfp.h>
+#include <linux/firmware.h>
+
+/*
+ * System Data internals
  *
  * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
+ * Copyright (C) 2015 Luis R. Rodriguez <mcgrof@do-not-panic.com>
+ *
  * Written by David Howells (dhowells@redhat.com)
  *
  * This program is free software; you can redistribute it and/or
@@ -9,5 +20,181 @@
  * 2 of the Licence, or (at your option) any later version.
  */
 
+struct sysdata_file {
+	size_t size;
+	const u8 *data;
+	bool sig_ok;
+
+	/* sysdata loader private fields */
+	void *priv;
+};
+
+enum sync_data_mode {
+	SYNCDATA_SYNC,
+	SYNCDATA_ASYNC,
+};
+
+/* one per sync_data_mode */
+union sysdata_file_cbs {
+	struct {
+		//int __must_check (*found_cb)(void *, const u8 *, const size_t);
+		int (*found_cb)(void *, const struct sysdata_file *);
+		void *found_context;
+
+		int (*opt_fail_cb)(void *);
+		void *opt_fail_context;
+	} sync;
+	struct {
+		void (*found_cb)(const struct sysdata_file *, void *);
+		void *found_context;
+
+		void (*opt_fail_cb)(void *);
+		void *opt_fail_context;
+	} async;
+};
+
+struct sysdata_file_sync_reqs {
+	enum sync_data_mode mode;
+	struct module *module;
+	gfp_t gfp;
+};
+
+/**
+ * struct sysdata_file_desc - system data file description
+ * @optional: if true it is not a hard requirement by the caller that this
+ *	file be present. An error will not be recorded if the file is not
+ *	found.
+ * @signature_required: if true a digital signature is required for this file.
+ * 	This is always true if you have a system with CONFIG_FIRMWARE_SIG_FORCE
+ * 	enabled.
+ * @sync_reqs: synchronization requirements, this will be taken care for you
+ *	by default if you are usingy sdata_file_request(), otherwise you
+ *	should provide your own requirements
+ *
+ * This structure is set the by the driver and passed to the system data
+ * file helpers sysdata_file_request() or sysdata_file_request_async().
+ * It is intended to carry all requirements and specifications required
+ * to complete the task to get the requested system date file to the caller.
+ * If you wish to extend functionality of system data file requests you
+ * should extend this data structure and make use of the extensions on
+ * the callers to avoid unnecessary collateral evolutions.
+ */
+struct sysdata_file_desc {
+	bool optional;
+	bool signature_required;
+	struct sysdata_file_sync_reqs sync_reqs;
+	union sysdata_file_cbs cbs;
+};
+
+#define SYSDATA_SYNC_FOUND(__found_cb, __context)			\
+	.cbs.sync.found_cb = __found_cb,				\
+	.cbs.sync.found_context = __context
+
+#define SYSDATA_SYNC_OPT_CB(__found_cb, __context)			\
+	.cbs.sync.opt_fail_cb = __found_cb,				\
+	.cbs.sync.opt_fail_context = __context
+
+/*
+ * Used to define the default asynchronization requirements for
+ * sysdata_file_request(). Drivers can only override callbacks.
+ */
+#define SYSDATA_DEFAULT_SYNC(__found_cb, __context)			\
+	.sync_reqs = {							\
+		.mode = SYNCDATA_SYNC,					\
+		.module = THIS_MODULE,					\
+		.gfp = GFP_KERNEL,					\
+	},								\
+	SYSDATA_SYNC_FOUND(__found_cb, __context)
+
+
+#define SYSDATA_ASYNC_FOUND(__found_cb, __context)			\
+	.cbs.async.found_cb = __found_cb,				\
+	.cbs.async.found_context = __context
+
+#define SYSDATA_ASYNC_OPT_CB(__found_cb, __context)			\
+	.cbs.async.opt_fail_cb = __found_cb,				\
+	.cbs.async.opt_fail_context = __context
+
+/*
+ * Used to define the default asynchronization requirements for
+ * sysdata_file_request_async(). Drivers can override.
+ */
+#define SYSDATA_DEFAULT_ASYNC(__found_cb, __context)			\
+	.sync_reqs = {							\
+		.mode = SYNCDATA_ASYNC,					\
+		.module = THIS_MODULE,					\
+		.gfp = GFP_KERNEL,					\
+	},								\
+	SYSDATA_ASYNC_FOUND(__found_cb, __context)
+
+#define desc_sync_found_cb(desc)	(desc->cbs.sync.found_cb)
+#define desc_sync_found_context(desc)	(desc->cbs.sync.found_context)
+static inline int desc_sync_found_call_cb(const struct sysdata_file_desc *desc,
+					  const struct sysdata_file *sysdata)
+{
+	if (!desc_sync_found_cb(desc))
+		return 0;
+	return desc_sync_found_cb(desc)(desc_sync_found_context(desc),
+					sysdata);
+}
+
+#define desc_sync_opt_cb(desc)		(desc->cbs.sync.opt_fail_cb)
+#define desc_sync_opt_context(desc)	(desc->cbs.sync.opt_fail_context)
+static inline int desc_sync_opt_call_cb(const struct sysdata_file_desc *desc)
+{
+	if (!desc_sync_opt_cb(desc))
+		return 0;
+	return desc_sync_opt_cb(desc)(desc_sync_opt_context(desc));
+}
+
+#define desc_async_found_cb(desc)	(desc->cbs.async.found_cb)
+#define desc_async_found_context(desc)	(desc->cbs.async.found_context)
+static inline void desc_async_found_call_cb(const struct sysdata_file *sysdata,
+					    const struct sysdata_file_desc *desc)
+{
+	if (!desc_async_found_cb(desc))
+		return;
+	desc_async_found_cb(desc)(sysdata, desc_async_found_context(desc));
+}
+
+#define desc_async_opt_cb(desc)		(desc->cbs.async.opt_fail_cb)
+#define desc_async_opt_context(desc)	(desc->cbs.async.opt_fail_context)
+static inline void desc_async_opt_call_cb(const struct sysdata_file_desc *desc)
+{
+	if (!desc_async_opt_cb(desc))
+		return;
+	desc_async_opt_cb(desc)(desc_async_opt_context(desc));
+}
+
 extern int sysdata_verify_sig(const void *data, unsigned long *_len);
 #define SYSDATA_SIG_STRING "~System data signature appended~\n"
+
+#if defined(CONFIG_FW_LOADER) || (defined(CONFIG_FW_LOADER_MODULE) && defined(MODULE))
+int sysdata_file_request(const char *name,
+			 const struct sysdata_file_desc *desc,
+			 struct device *device);
+int sysdata_file_request_async(const char *name,
+			       const struct sysdata_file_desc *desc,
+			       struct device *device);
+void release_sysdata_file(const struct sysdata_file *sysdata);
+#else
+static inline int sysdata_file_request(const char *name,
+				       const struct sysdata_file_desc *desc,
+				       struct device *device)
+{
+	return -EINVAL;
+}
+
+static inline int sysdata_file_request_async(const char *name,
+					     const struct sysdata_file_desc *desc,
+					     struct device *device);
+{
+	return -EINVAL;
+}
+
+static inline void release_sysdata_file(const struct sysdata_file *sysdata)
+{
+}
+#endif
+
+#endif /* _LINUX_SYSDATA_H */
-- 
2.3.2.209.gd67f9d5.dirty

[wireless-regdb] [RFC v1 07/12] firmware: add generic system data helpers with signature support

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

The Linux kernel has use cases for non-firmware file requests
from the filesystem. Some drivers, for instance the p54 driver,
uses the request_firmware() API to upload default EEPROM overrides.
Likewise, since the kernel already has cryptographic digital
signature verification support subsystems which have userspace
agents which historically have required cyptographic digital file
verification checks can replace those agents by using the kernel's
own digital verification checks on files requested from userspace.

At least for 802.11 and CRDA's [0] case for example, this is required
since CRDA has historically always had enabled digital signature
suppport on most distributions for the regulatory.bin file used to
store the 802.11 regulatory database. Providing an in-kernel replacement
should meet these same requirements unless of course distributions
start enabling digital firmware signature verification for all
required firmware. The keys for the signing regulatory data has
also been historically different than distribution's own keys
used for module signing.

There are a few motivations to replace userespace agents with these
crypto optional requirements:

  * there is a need for userspace / kernel sync up

  * the regulatory database ASCII format requires a binary
    converter and its format also needs to kept in sync
    for users that wish to have the regulatory database built
    into the kernel. Currently the ASCII db.txt file is parsed
    on the kernel through a fragile awk script. Keeping things
    in sync as the schema grows proves complex.

  * the kernel already has firmware-built-in support (see
    EXTRA_FIRMWARE) which can replace our own ASCII to db
    parser by letting us keep the firmware as binary in the
    kernel

The Linux integrity subsystem (IMA) provides a means [1] to enable
appraisal of files in userspace, this can also be used, however CRDA
has historically been used to vet for authenticity and integrity of
the regulatory database used for in-kernel 802.11 functionality.
Use of IMA is optional, support for digital signatures for files
used in-kernel can be have different subsystem specific requirements.

There's a few issues with extending the exisitng APIs however with
dynamic and custom cryptographic support. We keep pushing firmware
APIs by extending the number of arguments needed as requirements
grow or by adding new flags used internally for the different types
of new APIs exported. Behaviour can vary depending on whether a
usermode helper alternative is required, and we provide two types of
modes of operation: synchronous and asynchronous. Instead of
extending each of all these APIs with private flags this provides a
slim down implementation of what is required to get system data from
userspace to callers, without usermode helper alternative support
ripped out and by allowing the APIs to be extensible over time
depending on whether or not they are synchronous or asynchronous.

For now this initial implementation only provides an optional
requirement for subsystems to be able to override digital
signature support, for instance, even though firmware signing
might not have been enabled this lets distributions which have
had digital signature requirements for specifici files to upkeep
that tradition.

-- Consider this patch is incomplete as it still does not
   allow custom key specification, if distributions decided
   to only allow signed firmware we might be able to live with
   having distributions sign their own firmware and just stuff
   reguatory.bin into /lib/firmware. Distributions might wish
   to also make this call on their own as well.

   This patch is intended to help bring discussion about what
   we wish to do for the above requirements and also to help
   plan and coordinate future extensions to the firmware module
   and its APIs.

[0] https://wireless.wiki.kernel.org/en/developers/regulatory/crda
[1] http://sourceforge.net/p/linux-ima/wiki/Home/

Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/base/firmware_class.c | 256 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/sysdata.h       | 189 ++++++++++++++++++++++++++++++-
 2 files changed, 444 insertions(+), 1 deletion(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 55091b4..b46472b 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -39,6 +39,13 @@ MODULE_AUTHOR("Manuel Estrada Sainz");
 MODULE_DESCRIPTION("Multi purpose firmware loading support");
 MODULE_LICENSE("GPL");
 
+/* Should be a hot path as its the default */
+static const struct sysdata_file_sync_reqs __read_mostly dfl_sync_reqs = {
+	.mode = SYNCDATA_SYNC,
+	.module = THIS_MODULE,
+	.gfp = GFP_KERNEL,
+};
+
 static bool fw_sig_enforce = IS_ENABLED(CONFIG_FIRMWARE_SIG_FORCE);
 #ifndef CONFIG_FIRMWARE_SIG_FORCE
 module_param(fw_sig_enforce, bool_enable_only, 0644);
@@ -1266,6 +1273,179 @@ void release_firmware(const struct firmware *fw)
 }
 EXPORT_SYMBOL(release_firmware);
 
+static void sysdata_file_update(struct sysdata_file *sysdata)
+{
+	struct firmware *fw;
+	struct firmware_buf *buf;
+
+	if (!sysdata || !sysdata->priv)
+		return;
+
+	fw = sysdata->priv;
+	if (!fw->priv)
+		return;
+
+	buf = fw->priv;
+
+	sysdata->size = buf->size;
+	sysdata->data = buf->data;
+	sysdata->sig_ok = buf->sig_ok;
+
+	pr_debug("%s: fw-%s buf=%p data=%p size=%u sig_ok=%d\n",
+		 __func__, buf->fw_id, buf, buf->data,
+		 (unsigned int)buf->size, buf->sig_ok);
+}
+
+#ifdef CONFIG_FIRMWARE_SIG_FORCE
+static int sysdata_file_sig_check(const struct sysdata_file_desc *desc,
+				  struct firmware *fw)
+{
+	return firmware_sig_check(fw);
+}
+#else
+static int sysdata_file_sig_check(const struct sysdata_file_desc *desc,
+				  struct firmware *fw)
+{
+	int ret;
+
+	ret = firmware_sig_check(fw);
+	if (ret && !desc->signature_required)
+		ret = 0;
+
+	return ret;
+}
+#endif
+
+/* prepare firmware and firmware_buf structs;
+ * return 0 if a firmware is already assigned, 1 if need to load one,
+ * or a negative error code
+ */
+static int
+_request_sysdata_prepare(struct sysdata_file **sysdata_p, const char *name,
+			  struct device *device)
+{
+	struct sysdata_file *sysdata;
+	struct firmware *fw;
+	int ret;
+
+	*sysdata_p = sysdata = kzalloc(sizeof(*sysdata), GFP_KERNEL);
+	if (!sysdata) {
+		dev_err(device, "%s: kmalloc(struct sysdata) failed\n",
+			__func__);
+		return -ENOMEM;
+	}
+
+	ret = _request_firmware_prepare(&fw, name, device);
+	if (ret >= 0)
+		sysdata->priv = fw;
+
+	return ret;
+}
+
+/**
+ * release_sysdata_file: - release the resource associated with the sysdata file
+ * @sysdata_file: sysdata resource to release
+ **/
+void release_sysdata_file(const struct sysdata_file *sysdata)
+{
+	struct firmware *fw;
+
+	if (sysdata) {
+		if (sysdata->priv) {
+			fw = sysdata->priv;
+			release_firmware(fw);
+		}
+	}
+	kfree(sysdata);
+}
+EXPORT_SYMBOL_GPL(release_sysdata_file);
+
+static int _sysdata_file_request(const struct sysdata_file **sysdata_p,
+				 const char *name,
+				 const struct sysdata_file_desc *desc,
+				 struct device *device)
+{
+	struct sysdata_file *sysdata;
+	struct firmware *fw = NULL;
+	int ret;
+
+	if (!sysdata_p)
+		return -EINVAL;
+
+	if (!desc)
+		return -EINVAL;
+
+	if (!name || name[0] == '\0')
+		return -EINVAL;
+
+	ret = _request_sysdata_prepare(&sysdata, name, device);
+	if (ret <= 0) /* error or already assigned */
+		goto out;
+
+	fw = sysdata->priv;
+
+	ret = fw_get_filesystem_firmware(device, fw->priv);
+	if (ret && !desc->optional)
+		pr_err("Direct system data load for %s failed with error %d\n",
+		       name, ret);
+
+	if (!ret)
+		ret = assign_firmware_buf(fw, device, FW_OPT_UEVENT);
+
+ out:
+	if (ret >= 0)
+		ret = sysdata_file_sig_check(desc, fw);
+
+	if (ret < 0) {
+		release_sysdata_file(sysdata);
+		sysdata = NULL;
+	}
+
+	sysdata_file_update(sysdata);
+
+	*sysdata_p = sysdata;
+
+	return ret;
+}
+
+int sysdata_file_request(const char *name,
+			 const struct sysdata_file_desc *desc,
+			 struct device *device)
+{
+	const struct sysdata_file *sysdata;
+	const struct sysdata_file_sync_reqs *sync_reqs;
+	int ret;
+
+	if (!device || !desc || !name)
+		return -EINVAL;
+
+	/*
+	 * XXX: This Follows old behaviour which pegs onto *this* module,
+	 * but if we wanted to, if we knew all callers had
+	 * a valid THIS_MODULE, we'd peg this into their own
+	 * module instead.
+	 */
+	sync_reqs = &dfl_sync_reqs;
+
+	if (sync_reqs->mode != SYNCDATA_SYNC)
+		return -EINVAL;
+
+	__module_get(sync_reqs->module);
+	get_device(device);
+
+	ret = _sysdata_file_request(&sysdata, name, desc, device);
+	if (ret && desc->optional)
+		ret = desc_sync_opt_call_cb(desc);
+	else
+		ret = desc_sync_found_call_cb(desc, sysdata);
+
+	put_device(device);
+	module_put(sync_reqs->module);
+
+	return ret;
+}
+EXPORT_SYMBOL_GPL(sysdata_file_request);
+
 /* Async support */
 struct firmware_work {
 	struct work_struct work;
@@ -1350,6 +1530,82 @@ request_firmware_nowait(
 }
 EXPORT_SYMBOL(request_firmware_nowait);
 
+struct sysdata_file_work {
+	struct work_struct work;
+	const char *name;
+	struct sysdata_file_desc desc;
+	struct device *device;
+};
+
+static void request_sysdata_file_work_func(struct work_struct *work)
+{
+	struct sysdata_file_work *sys_work;
+	const struct sysdata_file_desc *desc;
+	const struct sysdata_file_sync_reqs *sync_reqs;
+	const struct sysdata_file *sysdata;
+	int ret;
+
+	sys_work = container_of(work, struct sysdata_file_work, work);
+	desc = &sys_work->desc;
+	sync_reqs = &desc->sync_reqs;
+
+	ret = _sysdata_file_request(&sysdata, sys_work->name,
+				    desc, sys_work->device);
+	if (ret && desc->optional)
+		desc_async_opt_call_cb(desc);
+	else
+		desc_async_found_call_cb(sysdata, desc);
+
+	put_device(sys_work->device);
+	module_put(sync_reqs->module);
+
+	kfree_const(sys_work->name);
+	kfree(sys_work);
+}
+
+int sysdata_file_request_async(const char *name,
+			       const struct sysdata_file_desc *desc,
+			       struct device *device)
+{
+	struct sysdata_file_work *sys_work;
+	const struct sysdata_file_sync_reqs *sync_reqs;
+
+	if (!device || !desc || !name)
+		return -EINVAL;
+
+	if (desc->sync_reqs.mode != SYNCDATA_ASYNC)
+		return -EINVAL;
+
+	if (!desc_async_found_cb(desc))
+		return -EINVAL;
+
+	sync_reqs = &desc->sync_reqs;
+
+	if (!sync_reqs->module)
+		return -EINVAL;
+
+	sys_work = kzalloc(sizeof(struct sysdata_file_work), sync_reqs->gfp);
+	if (!sys_work)
+		return -ENOMEM;
+
+	sys_work->desc = *desc;
+	sys_work->device = device;
+	sys_work->name = kstrdup_const(name, sync_reqs->gfp);
+
+	if (!try_module_get(sync_reqs->module)) {
+		kfree_const(sys_work->name);
+		kfree(sys_work);
+		return -EFAULT;
+	}
+
+	get_device(sys_work->device);
+	INIT_WORK(&sys_work->work, request_sysdata_file_work_func);
+	schedule_work(&sys_work->work);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(sysdata_file_request_async);
+
 #ifdef CONFIG_PM_SLEEP
 static ASYNC_DOMAIN_EXCLUSIVE(fw_cache_domain);
 
diff --git a/include/linux/sysdata.h b/include/linux/sysdata.h
index b40b873..b37c39d 100644
--- a/include/linux/sysdata.h
+++ b/include/linux/sysdata.h
@@ -1,6 +1,17 @@
-/* System Data internals
+#ifndef _LINUX_SYSDATA_H
+#define _LINUX_SYSDATA_H
+
+#include <linux/types.h>
+#include <linux/compiler.h>
+#include <linux/gfp.h>
+#include <linux/firmware.h>
+
+/*
+ * System Data internals
  *
  * Copyright (C) 2012 Red Hat, Inc. All Rights Reserved.
+ * Copyright (C) 2015 Luis R. Rodriguez <mcgrof@do-not-panic.com>
+ *
  * Written by David Howells (dhowells@redhat.com)
  *
  * This program is free software; you can redistribute it and/or
@@ -9,5 +20,181 @@
  * 2 of the Licence, or (at your option) any later version.
  */
 
+struct sysdata_file {
+	size_t size;
+	const u8 *data;
+	bool sig_ok;
+
+	/* sysdata loader private fields */
+	void *priv;
+};
+
+enum sync_data_mode {
+	SYNCDATA_SYNC,
+	SYNCDATA_ASYNC,
+};
+
+/* one per sync_data_mode */
+union sysdata_file_cbs {
+	struct {
+		//int __must_check (*found_cb)(void *, const u8 *, const size_t);
+		int (*found_cb)(void *, const struct sysdata_file *);
+		void *found_context;
+
+		int (*opt_fail_cb)(void *);
+		void *opt_fail_context;
+	} sync;
+	struct {
+		void (*found_cb)(const struct sysdata_file *, void *);
+		void *found_context;
+
+		void (*opt_fail_cb)(void *);
+		void *opt_fail_context;
+	} async;
+};
+
+struct sysdata_file_sync_reqs {
+	enum sync_data_mode mode;
+	struct module *module;
+	gfp_t gfp;
+};
+
+/**
+ * struct sysdata_file_desc - system data file description
+ * @optional: if true it is not a hard requirement by the caller that this
+ *	file be present. An error will not be recorded if the file is not
+ *	found.
+ * @signature_required: if true a digital signature is required for this file.
+ * 	This is always true if you have a system with CONFIG_FIRMWARE_SIG_FORCE
+ * 	enabled.
+ * @sync_reqs: synchronization requirements, this will be taken care for you
+ *	by default if you are usingy sdata_file_request(), otherwise you
+ *	should provide your own requirements
+ *
+ * This structure is set the by the driver and passed to the system data
+ * file helpers sysdata_file_request() or sysdata_file_request_async().
+ * It is intended to carry all requirements and specifications required
+ * to complete the task to get the requested system date file to the caller.
+ * If you wish to extend functionality of system data file requests you
+ * should extend this data structure and make use of the extensions on
+ * the callers to avoid unnecessary collateral evolutions.
+ */
+struct sysdata_file_desc {
+	bool optional;
+	bool signature_required;
+	struct sysdata_file_sync_reqs sync_reqs;
+	union sysdata_file_cbs cbs;
+};
+
+#define SYSDATA_SYNC_FOUND(__found_cb, __context)			\
+	.cbs.sync.found_cb = __found_cb,				\
+	.cbs.sync.found_context = __context
+
+#define SYSDATA_SYNC_OPT_CB(__found_cb, __context)			\
+	.cbs.sync.opt_fail_cb = __found_cb,				\
+	.cbs.sync.opt_fail_context = __context
+
+/*
+ * Used to define the default asynchronization requirements for
+ * sysdata_file_request(). Drivers can only override callbacks.
+ */
+#define SYSDATA_DEFAULT_SYNC(__found_cb, __context)			\
+	.sync_reqs = {							\
+		.mode = SYNCDATA_SYNC,					\
+		.module = THIS_MODULE,					\
+		.gfp = GFP_KERNEL,					\
+	},								\
+	SYSDATA_SYNC_FOUND(__found_cb, __context)
+
+
+#define SYSDATA_ASYNC_FOUND(__found_cb, __context)			\
+	.cbs.async.found_cb = __found_cb,				\
+	.cbs.async.found_context = __context
+
+#define SYSDATA_ASYNC_OPT_CB(__found_cb, __context)			\
+	.cbs.async.opt_fail_cb = __found_cb,				\
+	.cbs.async.opt_fail_context = __context
+
+/*
+ * Used to define the default asynchronization requirements for
+ * sysdata_file_request_async(). Drivers can override.
+ */
+#define SYSDATA_DEFAULT_ASYNC(__found_cb, __context)			\
+	.sync_reqs = {							\
+		.mode = SYNCDATA_ASYNC,					\
+		.module = THIS_MODULE,					\
+		.gfp = GFP_KERNEL,					\
+	},								\
+	SYSDATA_ASYNC_FOUND(__found_cb, __context)
+
+#define desc_sync_found_cb(desc)	(desc->cbs.sync.found_cb)
+#define desc_sync_found_context(desc)	(desc->cbs.sync.found_context)
+static inline int desc_sync_found_call_cb(const struct sysdata_file_desc *desc,
+					  const struct sysdata_file *sysdata)
+{
+	if (!desc_sync_found_cb(desc))
+		return 0;
+	return desc_sync_found_cb(desc)(desc_sync_found_context(desc),
+					sysdata);
+}
+
+#define desc_sync_opt_cb(desc)		(desc->cbs.sync.opt_fail_cb)
+#define desc_sync_opt_context(desc)	(desc->cbs.sync.opt_fail_context)
+static inline int desc_sync_opt_call_cb(const struct sysdata_file_desc *desc)
+{
+	if (!desc_sync_opt_cb(desc))
+		return 0;
+	return desc_sync_opt_cb(desc)(desc_sync_opt_context(desc));
+}
+
+#define desc_async_found_cb(desc)	(desc->cbs.async.found_cb)
+#define desc_async_found_context(desc)	(desc->cbs.async.found_context)
+static inline void desc_async_found_call_cb(const struct sysdata_file *sysdata,
+					    const struct sysdata_file_desc *desc)
+{
+	if (!desc_async_found_cb(desc))
+		return;
+	desc_async_found_cb(desc)(sysdata, desc_async_found_context(desc));
+}
+
+#define desc_async_opt_cb(desc)		(desc->cbs.async.opt_fail_cb)
+#define desc_async_opt_context(desc)	(desc->cbs.async.opt_fail_context)
+static inline void desc_async_opt_call_cb(const struct sysdata_file_desc *desc)
+{
+	if (!desc_async_opt_cb(desc))
+		return;
+	desc_async_opt_cb(desc)(desc_async_opt_context(desc));
+}
+
 extern int sysdata_verify_sig(const void *data, unsigned long *_len);
 #define SYSDATA_SIG_STRING "~System data signature appended~\n"
+
+#if defined(CONFIG_FW_LOADER) || (defined(CONFIG_FW_LOADER_MODULE) && defined(MODULE))
+int sysdata_file_request(const char *name,
+			 const struct sysdata_file_desc *desc,
+			 struct device *device);
+int sysdata_file_request_async(const char *name,
+			       const struct sysdata_file_desc *desc,
+			       struct device *device);
+void release_sysdata_file(const struct sysdata_file *sysdata);
+#else
+static inline int sysdata_file_request(const char *name,
+				       const struct sysdata_file_desc *desc,
+				       struct device *device)
+{
+	return -EINVAL;
+}
+
+static inline int sysdata_file_request_async(const char *name,
+					     const struct sysdata_file_desc *desc,
+					     struct device *device);
+{
+	return -EINVAL;
+}
+
+static inline void release_sysdata_file(const struct sysdata_file *sysdata)
+{
+}
+#endif
+
+#endif /* _LINUX_SYSDATA_H */
-- 
2.3.2.209.gd67f9d5.dirty


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

[RFC v1 08/12] p54spi: use sysdata_file_request() for EEPROM optional system data

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

This converts the driver over from request_firmware_direct() to
the sysdata_file_request().

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/net/wireless/p54/p54spi.c | 49 +++++++++++++++++++++++----------------
 1 file changed, 29 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index 63de5ee..0950ed6 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -24,6 +24,7 @@
 #include <linux/platform_device.h>
 #include <linux/interrupt.h>
 #include <linux/firmware.h>
+#include <linux/sysdata.h>
 #include <linux/delay.h>
 #include <linux/irq.h>
 #include <linux/spi/spi.h>
@@ -184,33 +185,41 @@ static int p54spi_request_firmware(struct ieee80211_hw *dev)
 	return 0;
 }
 
-static int p54spi_request_eeprom(struct ieee80211_hw *dev)
+static int p54spi_load_new_eeprom(void *context,
+				  const struct sysdata_file *sysdata)
 {
-	struct p54s_priv *priv = dev->priv;
-	const struct firmware *eeprom;
+	struct ieee80211_hw *dev = context;
 	int ret;
 
-	/* allow users to customize their eeprom.
-	 */
+	ret = p54_parse_eeprom(dev, (void *) sysdata->data,
+			       sysdata->size);
+	release_sysdata_file(sysdata);
 
-	ret = request_firmware_direct(&eeprom, "3826.eeprom", &priv->spi->dev);
-	if (ret < 0) {
-#ifdef CONFIG_P54_SPI_DEFAULT_EEPROM
-		dev_info(&priv->spi->dev, "loading default eeprom...\n");
-		ret = p54_parse_eeprom(dev, (void *) p54spi_eeprom,
-				       sizeof(p54spi_eeprom));
-#else
-		dev_err(&priv->spi->dev, "Failed to request user eeprom\n");
-#endif /* CONFIG_P54_SPI_DEFAULT_EEPROM */
-	} else {
-		dev_info(&priv->spi->dev, "loading user eeprom...\n");
-		ret = p54_parse_eeprom(dev, (void *) eeprom->data,
-				       (int)eeprom->size);
-		release_firmware(eeprom);
-	}
 	return ret;
 }
 
+static int p54spi_load_default_eeprom(void *context)
+{
+	struct ieee80211_hw *dev = context;
+
+	return p54_parse_eeprom(dev, (void *) p54spi_eeprom,
+				sizeof(p54spi_eeprom));
+}
+
+static int p54spi_request_eeprom(struct ieee80211_hw *dev)
+{
+	struct p54s_priv *priv = dev->priv;
+	const struct sysdata_file_desc p54_spi_eeprom_sysdata = {
+		SYSDATA_DEFAULT_SYNC(p54spi_load_new_eeprom, dev),
+		.optional = !IS_ENABLED(CONFIG_P54_SPI_DEFAULT_EEPROM),
+		SYSDATA_SYNC_OPT_CB(p54spi_load_default_eeprom, dev),
+	};
+
+	return sysdata_file_request("3826.eeprom",
+				    &p54_spi_eeprom_sysdata,
+				    &priv->spi->dev);
+}
+
 static int p54spi_upload_firmware(struct ieee80211_hw *dev)
 {
 	struct p54s_priv *priv = dev->priv;
-- 
2.3.2.209.gd67f9d5.dirty

[wireless-regdb] [RFC v1 08/12] p54spi: use sysdata_file_request() for EEPROM optional system data

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

This converts the driver over from request_firmware_direct() to
the sysdata_file_request().

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/net/wireless/p54/p54spi.c | 49 +++++++++++++++++++++++----------------
 1 file changed, 29 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index 63de5ee..0950ed6 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -24,6 +24,7 @@
 #include <linux/platform_device.h>
 #include <linux/interrupt.h>
 #include <linux/firmware.h>
+#include <linux/sysdata.h>
 #include <linux/delay.h>
 #include <linux/irq.h>
 #include <linux/spi/spi.h>
@@ -184,33 +185,41 @@ static int p54spi_request_firmware(struct ieee80211_hw *dev)
 	return 0;
 }
 
-static int p54spi_request_eeprom(struct ieee80211_hw *dev)
+static int p54spi_load_new_eeprom(void *context,
+				  const struct sysdata_file *sysdata)
 {
-	struct p54s_priv *priv = dev->priv;
-	const struct firmware *eeprom;
+	struct ieee80211_hw *dev = context;
 	int ret;
 
-	/* allow users to customize their eeprom.
-	 */
+	ret = p54_parse_eeprom(dev, (void *) sysdata->data,
+			       sysdata->size);
+	release_sysdata_file(sysdata);
 
-	ret = request_firmware_direct(&eeprom, "3826.eeprom", &priv->spi->dev);
-	if (ret < 0) {
-#ifdef CONFIG_P54_SPI_DEFAULT_EEPROM
-		dev_info(&priv->spi->dev, "loading default eeprom...\n");
-		ret = p54_parse_eeprom(dev, (void *) p54spi_eeprom,
-				       sizeof(p54spi_eeprom));
-#else
-		dev_err(&priv->spi->dev, "Failed to request user eeprom\n");
-#endif /* CONFIG_P54_SPI_DEFAULT_EEPROM */
-	} else {
-		dev_info(&priv->spi->dev, "loading user eeprom...\n");
-		ret = p54_parse_eeprom(dev, (void *) eeprom->data,
-				       (int)eeprom->size);
-		release_firmware(eeprom);
-	}
 	return ret;
 }
 
+static int p54spi_load_default_eeprom(void *context)
+{
+	struct ieee80211_hw *dev = context;
+
+	return p54_parse_eeprom(dev, (void *) p54spi_eeprom,
+				sizeof(p54spi_eeprom));
+}
+
+static int p54spi_request_eeprom(struct ieee80211_hw *dev)
+{
+	struct p54s_priv *priv = dev->priv;
+	const struct sysdata_file_desc p54_spi_eeprom_sysdata = {
+		SYSDATA_DEFAULT_SYNC(p54spi_load_new_eeprom, dev),
+		.optional = !IS_ENABLED(CONFIG_P54_SPI_DEFAULT_EEPROM),
+		SYSDATA_SYNC_OPT_CB(p54spi_load_default_eeprom, dev),
+	};
+
+	return sysdata_file_request("3826.eeprom",
+				    &p54_spi_eeprom_sysdata,
+				    &priv->spi->dev);
+}
+
 static int p54spi_upload_firmware(struct ieee80211_hw *dev)
 {
 	struct p54s_priv *priv = dev->priv;
-- 
2.3.2.209.gd67f9d5.dirty


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

[RFC v1 09/12] p54: use sysdata_file_request() and sysdata_file_request_async()

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

This is an example conversion of the p54 driver firmware calls
over to sysdata_file_request() and sysdata_file_request_async().

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/net/wireless/p54/eeprom.c |  1 -
 drivers/net/wireless/p54/fwio.c   |  4 ++--
 drivers/net/wireless/p54/led.c    |  1 -
 drivers/net/wireless/p54/main.c   |  1 -
 drivers/net/wireless/p54/p54.h    |  4 +++-
 drivers/net/wireless/p54/p54pci.c | 19 +++++++++++++------
 drivers/net/wireless/p54/p54pci.h |  2 +-
 drivers/net/wireless/p54/p54spi.c | 25 ++++++-------------------
 drivers/net/wireless/p54/p54spi.h |  2 +-
 drivers/net/wireless/p54/p54usb.c | 14 ++++++++------
 drivers/net/wireless/p54/p54usb.h |  2 +-
 drivers/net/wireless/p54/txrx.c   |  1 -
 12 files changed, 35 insertions(+), 41 deletions(-)

diff --git a/drivers/net/wireless/p54/eeprom.c b/drivers/net/wireless/p54/eeprom.c
index 2fe713e..0ad3434 100644
--- a/drivers/net/wireless/p54/eeprom.c
+++ b/drivers/net/wireless/p54/eeprom.c
@@ -16,7 +16,6 @@
  * published by the Free Software Foundation.
  */
 
-#include <linux/firmware.h>
 #include <linux/etherdevice.h>
 #include <linux/sort.h>
 #include <linux/slab.h>
diff --git a/drivers/net/wireless/p54/fwio.c b/drivers/net/wireless/p54/fwio.c
index 5367d51..2bfe34d 100644
--- a/drivers/net/wireless/p54/fwio.c
+++ b/drivers/net/wireless/p54/fwio.c
@@ -17,7 +17,6 @@
  */
 
 #include <linux/slab.h>
-#include <linux/firmware.h>
 #include <linux/etherdevice.h>
 #include <linux/export.h>
 
@@ -27,8 +26,9 @@
 #include "eeprom.h"
 #include "lmac.h"
 
-int p54_parse_firmware(struct ieee80211_hw *dev, const struct firmware *fw)
+int p54_parse_firmware(void *context, const struct sysdata_file *fw)
 {
+	struct ieee80211_hw *dev = context;
 	struct p54_common *priv = dev->priv;
 	struct exp_if *exp_if;
 	struct bootrec *bootrec;
diff --git a/drivers/net/wireless/p54/led.c b/drivers/net/wireless/p54/led.c
index 1f6fd5f..96aaefb 100644
--- a/drivers/net/wireless/p54/led.c
+++ b/drivers/net/wireless/p54/led.c
@@ -16,7 +16,6 @@
  * published by the Free Software Foundation.
  */
 
-#include <linux/firmware.h>
 #include <linux/etherdevice.h>
 
 #include <net/mac80211.h>
diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
index b9250d7..a6ade6e 100644
--- a/drivers/net/wireless/p54/main.c
+++ b/drivers/net/wireless/p54/main.c
@@ -17,7 +17,6 @@
  */
 
 #include <linux/slab.h>
-#include <linux/firmware.h>
 #include <linux/etherdevice.h>
 #include <linux/module.h>
 
diff --git a/drivers/net/wireless/p54/p54.h b/drivers/net/wireless/p54/p54.h
index 40b401e..239b649 100644
--- a/drivers/net/wireless/p54/p54.h
+++ b/drivers/net/wireless/p54/p54.h
@@ -14,6 +14,8 @@
 #ifndef P54_H
 #define P54_H
 
+#include <linux/sysdata.h>
+
 #ifdef CONFIG_P54_LEDS
 #include <linux/leds.h>
 #endif /* CONFIG_P54_LEDS */
@@ -268,7 +270,7 @@ struct p54_common {
 /* interfaces for the drivers */
 int p54_rx(struct ieee80211_hw *dev, struct sk_buff *skb);
 void p54_free_skb(struct ieee80211_hw *dev, struct sk_buff *skb);
-int p54_parse_firmware(struct ieee80211_hw *dev, const struct firmware *fw);
+int p54_parse_firmware(void *, const struct sysdata_file *);
 int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len);
 int p54_read_eeprom(struct ieee80211_hw *dev);
 
diff --git a/drivers/net/wireless/p54/p54pci.c b/drivers/net/wireless/p54/p54pci.c
index 27a4906..b5deb09 100644
--- a/drivers/net/wireless/p54/p54pci.c
+++ b/drivers/net/wireless/p54/p54pci.c
@@ -15,7 +15,6 @@
 
 #include <linux/pci.h>
 #include <linux/slab.h>
-#include <linux/firmware.h>
 #include <linux/etherdevice.h>
 #include <linux/delay.h>
 #include <linux/completion.h>
@@ -490,7 +489,7 @@ static int p54p_open(struct ieee80211_hw *dev)
 	return 0;
 }
 
-static void p54p_firmware_step2(const struct firmware *fw,
+static void p54p_firmware_step2(const struct sysdata_file *fw,
 				void *context)
 {
 	struct p54p_priv *priv = context;
@@ -542,6 +541,16 @@ out:
 	pci_dev_put(pdev);
 }
 
+static int p54p_request_fw_step2(struct p54p_priv *priv)
+{
+	const struct sysdata_file_desc p54p_fw_step2_desc = {
+		SYSDATA_DEFAULT_ASYNC(p54p_firmware_step2, priv),
+	};
+	return sysdata_file_request_async("isl3886pci",
+					  &p54p_fw_step2_desc,
+					  &priv->pdev->dev);
+}
+
 static int p54p_probe(struct pci_dev *pdev,
 				const struct pci_device_id *id)
 {
@@ -620,9 +629,7 @@ static int p54p_probe(struct pci_dev *pdev,
 	spin_lock_init(&priv->lock);
 	tasklet_init(&priv->tasklet, p54p_tasklet, (unsigned long)dev);
 
-	err = request_firmware_nowait(THIS_MODULE, 1, "isl3886pci",
-				      &priv->pdev->dev, GFP_KERNEL,
-				      priv, p54p_firmware_step2);
+	err = p54p_request_fw_step2(priv);
 	if (!err)
 		return 0;
 
@@ -654,7 +661,7 @@ static void p54p_remove(struct pci_dev *pdev)
 	priv = dev->priv;
 	wait_for_completion(&priv->fw_loaded);
 	p54_unregister_common(dev);
-	release_firmware(priv->firmware);
+	release_sysdata_file(priv->firmware);
 	pci_free_consistent(pdev, sizeof(*priv->ring_control),
 			    priv->ring_control, priv->ring_control_dma);
 	iounmap(priv->map);
diff --git a/drivers/net/wireless/p54/p54pci.h b/drivers/net/wireless/p54/p54pci.h
index 68405c1..55870bf 100644
--- a/drivers/net/wireless/p54/p54pci.h
+++ b/drivers/net/wireless/p54/p54pci.h
@@ -94,7 +94,7 @@ struct p54p_priv {
 	struct pci_dev *pdev;
 	struct p54p_csr __iomem *map;
 	struct tasklet_struct tasklet;
-	const struct firmware *firmware;
+	const struct sysdata_file *firmware;
 	spinlock_t lock;
 	struct p54p_ring_control *ring_control;
 	dma_addr_t ring_control_dma;
diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index 0950ed6..24155d2 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -23,8 +23,6 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/interrupt.h>
-#include <linux/firmware.h>
-#include <linux/sysdata.h>
 #include <linux/delay.h>
 #include <linux/irq.h>
 #include <linux/spi/spi.h>
@@ -166,22 +164,11 @@ static int p54spi_spi_write_dma(struct p54s_priv *priv, __le32 base,
 static int p54spi_request_firmware(struct ieee80211_hw *dev)
 {
 	struct p54s_priv *priv = dev->priv;
-	int ret;
-
-	/* FIXME: should driver use it's own struct device? */
-	ret = request_firmware(&priv->firmware, "3826.arm", &priv->spi->dev);
-
-	if (ret < 0) {
-		dev_err(&priv->spi->dev, "request_firmware() failed: %d", ret);
-		return ret;
-	}
-
-	ret = p54_parse_firmware(dev, priv->firmware);
-	if (ret) {
-		release_firmware(priv->firmware);
-		return ret;
-	}
-
+	const struct sysdata_file_desc p54_spi_fw = {
+		SYSDATA_DEFAULT_SYNC(p54_parse_firmware, priv),
+	};
+	return sysdata_file_request("3826.arm", &p54_spi_fw,
+				    &priv->spi->dev);
 	return 0;
 }
 
@@ -701,7 +688,7 @@ static int p54spi_remove(struct spi_device *spi)
 
 	gpio_free(p54spi_gpio_power);
 	gpio_free(p54spi_gpio_irq);
-	release_firmware(priv->firmware);
+	release_sysdata_file(priv->firmware);
 
 	mutex_destroy(&priv->mutex);
 
diff --git a/drivers/net/wireless/p54/p54spi.h b/drivers/net/wireless/p54/p54spi.h
index dfaa62a..f4f20ff 100644
--- a/drivers/net/wireless/p54/p54spi.h
+++ b/drivers/net/wireless/p54/p54spi.h
@@ -119,7 +119,7 @@ struct p54s_priv {
 	struct list_head tx_pending;
 
 	enum fw_state fw_state;
-	const struct firmware *firmware;
+	const struct sysdata_file *firmware;
 };
 
 #endif /* P54SPI_H */
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index 043bd1c..5eb1b53 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -15,7 +15,6 @@
 #include <linux/usb.h>
 #include <linux/pci.h>
 #include <linux/slab.h>
-#include <linux/firmware.h>
 #include <linux/etherdevice.h>
 #include <linux/delay.h>
 #include <linux/crc32.h>
@@ -916,7 +915,7 @@ err_out:
 	return ret;
 }
 
-static void p54u_load_firmware_cb(const struct firmware *firmware,
+static void p54u_load_firmware_cb(const struct sysdata_file *firmware,
 				  void *context)
 {
 	struct p54u_priv *priv = context;
@@ -960,6 +959,9 @@ static int p54u_load_firmware(struct ieee80211_hw *dev,
 	struct usb_device *udev = interface_to_usbdev(intf);
 	struct p54u_priv *priv = dev->priv;
 	struct device *device = &udev->dev;
+	const struct sysdata_file_desc p54u_fw_desc = {
+		SYSDATA_DEFAULT_ASYNC(p54u_load_firmware_cb, priv),
+	};
 	int err, i;
 
 	BUILD_BUG_ON(ARRAY_SIZE(p54u_fwlist) != __NUM_P54U_HWTYPES);
@@ -973,9 +975,9 @@ static int p54u_load_firmware(struct ieee80211_hw *dev,
 	       p54u_fwlist[i].fw);
 
 	usb_get_dev(udev);
-	err = request_firmware_nowait(THIS_MODULE, 1, p54u_fwlist[i].fw,
-				      device, GFP_KERNEL, priv,
-				      p54u_load_firmware_cb);
+	err = sysdata_file_request_async(p54u_fwlist[i].fw,
+					 &p54u_fw_desc,
+					 device);
 	if (err) {
 		dev_err(&priv->udev->dev, "(p54usb) cannot load firmware %s "
 					  "(%d)!\n", p54u_fwlist[i].fw, err);
@@ -1073,7 +1075,7 @@ static void p54u_disconnect(struct usb_interface *intf)
 	p54_unregister_common(dev);
 
 	usb_put_dev(interface_to_usbdev(intf));
-	release_firmware(priv->fw);
+	release_sysdata_file(priv->fw);
 	p54_free_common(dev);
 }
 
diff --git a/drivers/net/wireless/p54/p54usb.h b/drivers/net/wireless/p54/p54usb.h
index a5f5f0f..9da200b 100644
--- a/drivers/net/wireless/p54/p54usb.h
+++ b/drivers/net/wireless/p54/p54usb.h
@@ -153,7 +153,7 @@ struct p54u_priv {
 	spinlock_t lock;
 	struct sk_buff_head rx_queue;
 	struct usb_anchor submitted;
-	const struct firmware *fw;
+	const struct sysdata_file *fw;
 
 	/* asynchronous firmware callback */
 	struct completion fw_wait_load;
diff --git a/drivers/net/wireless/p54/txrx.c b/drivers/net/wireless/p54/txrx.c
index 24e5ff9..2d9dee0 100644
--- a/drivers/net/wireless/p54/txrx.c
+++ b/drivers/net/wireless/p54/txrx.c
@@ -17,7 +17,6 @@
  */
 
 #include <linux/export.h>
-#include <linux/firmware.h>
 #include <linux/etherdevice.h>
 #include <asm/div64.h>
 
-- 
2.3.2.209.gd67f9d5.dirty

[wireless-regdb] [RFC v1 09/12] p54: use sysdata_file_request() and sysdata_file_request_async()

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

This is an example conversion of the p54 driver firmware calls
over to sysdata_file_request() and sysdata_file_request_async().

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/net/wireless/p54/eeprom.c |  1 -
 drivers/net/wireless/p54/fwio.c   |  4 ++--
 drivers/net/wireless/p54/led.c    |  1 -
 drivers/net/wireless/p54/main.c   |  1 -
 drivers/net/wireless/p54/p54.h    |  4 +++-
 drivers/net/wireless/p54/p54pci.c | 19 +++++++++++++------
 drivers/net/wireless/p54/p54pci.h |  2 +-
 drivers/net/wireless/p54/p54spi.c | 25 ++++++-------------------
 drivers/net/wireless/p54/p54spi.h |  2 +-
 drivers/net/wireless/p54/p54usb.c | 14 ++++++++------
 drivers/net/wireless/p54/p54usb.h |  2 +-
 drivers/net/wireless/p54/txrx.c   |  1 -
 12 files changed, 35 insertions(+), 41 deletions(-)

diff --git a/drivers/net/wireless/p54/eeprom.c b/drivers/net/wireless/p54/eeprom.c
index 2fe713e..0ad3434 100644
--- a/drivers/net/wireless/p54/eeprom.c
+++ b/drivers/net/wireless/p54/eeprom.c
@@ -16,7 +16,6 @@
  * published by the Free Software Foundation.
  */
 
-#include <linux/firmware.h>
 #include <linux/etherdevice.h>
 #include <linux/sort.h>
 #include <linux/slab.h>
diff --git a/drivers/net/wireless/p54/fwio.c b/drivers/net/wireless/p54/fwio.c
index 5367d51..2bfe34d 100644
--- a/drivers/net/wireless/p54/fwio.c
+++ b/drivers/net/wireless/p54/fwio.c
@@ -17,7 +17,6 @@
  */
 
 #include <linux/slab.h>
-#include <linux/firmware.h>
 #include <linux/etherdevice.h>
 #include <linux/export.h>
 
@@ -27,8 +26,9 @@
 #include "eeprom.h"
 #include "lmac.h"
 
-int p54_parse_firmware(struct ieee80211_hw *dev, const struct firmware *fw)
+int p54_parse_firmware(void *context, const struct sysdata_file *fw)
 {
+	struct ieee80211_hw *dev = context;
 	struct p54_common *priv = dev->priv;
 	struct exp_if *exp_if;
 	struct bootrec *bootrec;
diff --git a/drivers/net/wireless/p54/led.c b/drivers/net/wireless/p54/led.c
index 1f6fd5f..96aaefb 100644
--- a/drivers/net/wireless/p54/led.c
+++ b/drivers/net/wireless/p54/led.c
@@ -16,7 +16,6 @@
  * published by the Free Software Foundation.
  */
 
-#include <linux/firmware.h>
 #include <linux/etherdevice.h>
 
 #include <net/mac80211.h>
diff --git a/drivers/net/wireless/p54/main.c b/drivers/net/wireless/p54/main.c
index b9250d7..a6ade6e 100644
--- a/drivers/net/wireless/p54/main.c
+++ b/drivers/net/wireless/p54/main.c
@@ -17,7 +17,6 @@
  */
 
 #include <linux/slab.h>
-#include <linux/firmware.h>
 #include <linux/etherdevice.h>
 #include <linux/module.h>
 
diff --git a/drivers/net/wireless/p54/p54.h b/drivers/net/wireless/p54/p54.h
index 40b401e..239b649 100644
--- a/drivers/net/wireless/p54/p54.h
+++ b/drivers/net/wireless/p54/p54.h
@@ -14,6 +14,8 @@
 #ifndef P54_H
 #define P54_H
 
+#include <linux/sysdata.h>
+
 #ifdef CONFIG_P54_LEDS
 #include <linux/leds.h>
 #endif /* CONFIG_P54_LEDS */
@@ -268,7 +270,7 @@ struct p54_common {
 /* interfaces for the drivers */
 int p54_rx(struct ieee80211_hw *dev, struct sk_buff *skb);
 void p54_free_skb(struct ieee80211_hw *dev, struct sk_buff *skb);
-int p54_parse_firmware(struct ieee80211_hw *dev, const struct firmware *fw);
+int p54_parse_firmware(void *, const struct sysdata_file *);
 int p54_parse_eeprom(struct ieee80211_hw *dev, void *eeprom, int len);
 int p54_read_eeprom(struct ieee80211_hw *dev);
 
diff --git a/drivers/net/wireless/p54/p54pci.c b/drivers/net/wireless/p54/p54pci.c
index 27a4906..b5deb09 100644
--- a/drivers/net/wireless/p54/p54pci.c
+++ b/drivers/net/wireless/p54/p54pci.c
@@ -15,7 +15,6 @@
 
 #include <linux/pci.h>
 #include <linux/slab.h>
-#include <linux/firmware.h>
 #include <linux/etherdevice.h>
 #include <linux/delay.h>
 #include <linux/completion.h>
@@ -490,7 +489,7 @@ static int p54p_open(struct ieee80211_hw *dev)
 	return 0;
 }
 
-static void p54p_firmware_step2(const struct firmware *fw,
+static void p54p_firmware_step2(const struct sysdata_file *fw,
 				void *context)
 {
 	struct p54p_priv *priv = context;
@@ -542,6 +541,16 @@ out:
 	pci_dev_put(pdev);
 }
 
+static int p54p_request_fw_step2(struct p54p_priv *priv)
+{
+	const struct sysdata_file_desc p54p_fw_step2_desc = {
+		SYSDATA_DEFAULT_ASYNC(p54p_firmware_step2, priv),
+	};
+	return sysdata_file_request_async("isl3886pci",
+					  &p54p_fw_step2_desc,
+					  &priv->pdev->dev);
+}
+
 static int p54p_probe(struct pci_dev *pdev,
 				const struct pci_device_id *id)
 {
@@ -620,9 +629,7 @@ static int p54p_probe(struct pci_dev *pdev,
 	spin_lock_init(&priv->lock);
 	tasklet_init(&priv->tasklet, p54p_tasklet, (unsigned long)dev);
 
-	err = request_firmware_nowait(THIS_MODULE, 1, "isl3886pci",
-				      &priv->pdev->dev, GFP_KERNEL,
-				      priv, p54p_firmware_step2);
+	err = p54p_request_fw_step2(priv);
 	if (!err)
 		return 0;
 
@@ -654,7 +661,7 @@ static void p54p_remove(struct pci_dev *pdev)
 	priv = dev->priv;
 	wait_for_completion(&priv->fw_loaded);
 	p54_unregister_common(dev);
-	release_firmware(priv->firmware);
+	release_sysdata_file(priv->firmware);
 	pci_free_consistent(pdev, sizeof(*priv->ring_control),
 			    priv->ring_control, priv->ring_control_dma);
 	iounmap(priv->map);
diff --git a/drivers/net/wireless/p54/p54pci.h b/drivers/net/wireless/p54/p54pci.h
index 68405c1..55870bf 100644
--- a/drivers/net/wireless/p54/p54pci.h
+++ b/drivers/net/wireless/p54/p54pci.h
@@ -94,7 +94,7 @@ struct p54p_priv {
 	struct pci_dev *pdev;
 	struct p54p_csr __iomem *map;
 	struct tasklet_struct tasklet;
-	const struct firmware *firmware;
+	const struct sysdata_file *firmware;
 	spinlock_t lock;
 	struct p54p_ring_control *ring_control;
 	dma_addr_t ring_control_dma;
diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index 0950ed6..24155d2 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -23,8 +23,6 @@
 #include <linux/module.h>
 #include <linux/platform_device.h>
 #include <linux/interrupt.h>
-#include <linux/firmware.h>
-#include <linux/sysdata.h>
 #include <linux/delay.h>
 #include <linux/irq.h>
 #include <linux/spi/spi.h>
@@ -166,22 +164,11 @@ static int p54spi_spi_write_dma(struct p54s_priv *priv, __le32 base,
 static int p54spi_request_firmware(struct ieee80211_hw *dev)
 {
 	struct p54s_priv *priv = dev->priv;
-	int ret;
-
-	/* FIXME: should driver use it's own struct device? */
-	ret = request_firmware(&priv->firmware, "3826.arm", &priv->spi->dev);
-
-	if (ret < 0) {
-		dev_err(&priv->spi->dev, "request_firmware() failed: %d", ret);
-		return ret;
-	}
-
-	ret = p54_parse_firmware(dev, priv->firmware);
-	if (ret) {
-		release_firmware(priv->firmware);
-		return ret;
-	}
-
+	const struct sysdata_file_desc p54_spi_fw = {
+		SYSDATA_DEFAULT_SYNC(p54_parse_firmware, priv),
+	};
+	return sysdata_file_request("3826.arm", &p54_spi_fw,
+				    &priv->spi->dev);
 	return 0;
 }
 
@@ -701,7 +688,7 @@ static int p54spi_remove(struct spi_device *spi)
 
 	gpio_free(p54spi_gpio_power);
 	gpio_free(p54spi_gpio_irq);
-	release_firmware(priv->firmware);
+	release_sysdata_file(priv->firmware);
 
 	mutex_destroy(&priv->mutex);
 
diff --git a/drivers/net/wireless/p54/p54spi.h b/drivers/net/wireless/p54/p54spi.h
index dfaa62a..f4f20ff 100644
--- a/drivers/net/wireless/p54/p54spi.h
+++ b/drivers/net/wireless/p54/p54spi.h
@@ -119,7 +119,7 @@ struct p54s_priv {
 	struct list_head tx_pending;
 
 	enum fw_state fw_state;
-	const struct firmware *firmware;
+	const struct sysdata_file *firmware;
 };
 
 #endif /* P54SPI_H */
diff --git a/drivers/net/wireless/p54/p54usb.c b/drivers/net/wireless/p54/p54usb.c
index 043bd1c..5eb1b53 100644
--- a/drivers/net/wireless/p54/p54usb.c
+++ b/drivers/net/wireless/p54/p54usb.c
@@ -15,7 +15,6 @@
 #include <linux/usb.h>
 #include <linux/pci.h>
 #include <linux/slab.h>
-#include <linux/firmware.h>
 #include <linux/etherdevice.h>
 #include <linux/delay.h>
 #include <linux/crc32.h>
@@ -916,7 +915,7 @@ err_out:
 	return ret;
 }
 
-static void p54u_load_firmware_cb(const struct firmware *firmware,
+static void p54u_load_firmware_cb(const struct sysdata_file *firmware,
 				  void *context)
 {
 	struct p54u_priv *priv = context;
@@ -960,6 +959,9 @@ static int p54u_load_firmware(struct ieee80211_hw *dev,
 	struct usb_device *udev = interface_to_usbdev(intf);
 	struct p54u_priv *priv = dev->priv;
 	struct device *device = &udev->dev;
+	const struct sysdata_file_desc p54u_fw_desc = {
+		SYSDATA_DEFAULT_ASYNC(p54u_load_firmware_cb, priv),
+	};
 	int err, i;
 
 	BUILD_BUG_ON(ARRAY_SIZE(p54u_fwlist) != __NUM_P54U_HWTYPES);
@@ -973,9 +975,9 @@ static int p54u_load_firmware(struct ieee80211_hw *dev,
 	       p54u_fwlist[i].fw);
 
 	usb_get_dev(udev);
-	err = request_firmware_nowait(THIS_MODULE, 1, p54u_fwlist[i].fw,
-				      device, GFP_KERNEL, priv,
-				      p54u_load_firmware_cb);
+	err = sysdata_file_request_async(p54u_fwlist[i].fw,
+					 &p54u_fw_desc,
+					 device);
 	if (err) {
 		dev_err(&priv->udev->dev, "(p54usb) cannot load firmware %s "
 					  "(%d)!\n", p54u_fwlist[i].fw, err);
@@ -1073,7 +1075,7 @@ static void p54u_disconnect(struct usb_interface *intf)
 	p54_unregister_common(dev);
 
 	usb_put_dev(interface_to_usbdev(intf));
-	release_firmware(priv->fw);
+	release_sysdata_file(priv->fw);
 	p54_free_common(dev);
 }
 
diff --git a/drivers/net/wireless/p54/p54usb.h b/drivers/net/wireless/p54/p54usb.h
index a5f5f0f..9da200b 100644
--- a/drivers/net/wireless/p54/p54usb.h
+++ b/drivers/net/wireless/p54/p54usb.h
@@ -153,7 +153,7 @@ struct p54u_priv {
 	spinlock_t lock;
 	struct sk_buff_head rx_queue;
 	struct usb_anchor submitted;
-	const struct firmware *fw;
+	const struct sysdata_file *fw;
 
 	/* asynchronous firmware callback */
 	struct completion fw_wait_load;
diff --git a/drivers/net/wireless/p54/txrx.c b/drivers/net/wireless/p54/txrx.c
index 24e5ff9..2d9dee0 100644
--- a/drivers/net/wireless/p54/txrx.c
+++ b/drivers/net/wireless/p54/txrx.c
@@ -17,7 +17,6 @@
  */
 
 #include <linux/export.h>
-#include <linux/firmware.h>
 #include <linux/etherdevice.h>
 #include <asm/div64.h>
 
-- 
2.3.2.209.gd67f9d5.dirty


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

[RFC v1 10/12] ath9k_htc: use sysdata_file_request() and sysdata_file_request_async()

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/net/wireless/ath/ath9k/hif_usb.c | 62 +++++++++++++++++++-------------
 1 file changed, 38 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 8e7153b..bc7591c 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -15,6 +15,7 @@
  */
 
 #include <asm/unaligned.h>
+#include <linux/sysdata.h>
 #include "htc.h"
 
 /* identify firmware images */
@@ -1079,7 +1080,8 @@ static void ath9k_hif_usb_firmware_fail(struct hif_device_usb *hif_dev)
 		device_unlock(parent);
 }
 
-static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void *context)
+static void ath9k_hif_usb_firmware_cb(const struct sysdata_file *fw,
+				      void *context)
 {
 	struct hif_device_usb *hif_dev = context;
 	int ret;
@@ -1115,7 +1117,7 @@ static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void *context)
 		goto err_htc_hw_init;
 	}
 
-	release_firmware(fw);
+	release_sysdata_file(fw);
 	hif_dev->flags |= HIF_USB_READY;
 	complete_all(&hif_dev->fw_done);
 
@@ -1126,7 +1128,7 @@ err_htc_hw_init:
 err_dev_init:
 	ath9k_htc_hw_free(hif_dev->htc_handle);
 err_dev_alloc:
-	release_firmware(fw);
+	release_sysdata_file(fw);
 err_fw:
 	ath9k_hif_usb_firmware_fail(hif_dev);
 }
@@ -1186,6 +1188,16 @@ static int send_eject_command(struct usb_interface *interface)
 	return 0;
 }
 
+int ath9k_hif_usb_probe_fw(struct hif_device_usb *hif_dev)
+{
+	const struct sysdata_file_desc fw_desc = {
+		SYSDATA_DEFAULT_ASYNC(ath9k_hif_usb_firmware_cb, hif_dev),
+	};
+
+	return sysdata_file_request_async(hif_dev->fw_name, &fw_desc,
+					  &hif_dev->udev->dev);
+}
+
 static int ath9k_hif_usb_probe(struct usb_interface *interface,
 			       const struct usb_device_id *id)
 {
@@ -1221,18 +1233,9 @@ static int ath9k_hif_usb_probe(struct usb_interface *interface,
 	else
 		hif_dev->fw_name = FIRMWARE_AR9271;
 
-	ret = request_firmware_nowait(THIS_MODULE, true, hif_dev->fw_name,
-				      &hif_dev->udev->dev, GFP_KERNEL,
-				      hif_dev, ath9k_hif_usb_firmware_cb);
-	if (ret) {
-		dev_err(&hif_dev->udev->dev,
-			"ath9k_htc: Async request for firmware %s failed\n",
-			hif_dev->fw_name);
+	ret = ath9k_hif_usb_probe_fw(hif_dev);
+	if (ret)
 		goto err_fw_req;
-	}
-
-	dev_info(&hif_dev->udev->dev, "ath9k_htc: Firmware %s requested\n",
-		 hif_dev->fw_name);
 
 	return 0;
 
@@ -1312,12 +1315,30 @@ static int ath9k_hif_usb_suspend(struct usb_interface *interface,
 	return 0;
 }
 
+static int ath9k_hif_usb_resume_fw(void *context,
+				   const struct sysdata_file *fw)
+{
+	struct hif_device_usb *hif_dev = context;
+	int ret;
+
+	hif_dev->fw_data = fw->data;
+	hif_dev->fw_size = fw->size;
+
+	ret = ath9k_hif_usb_download_fw(hif_dev);
+
+	release_sysdata_file(fw);
+
+	return ret;
+}
+
 static int ath9k_hif_usb_resume(struct usb_interface *interface)
 {
 	struct hif_device_usb *hif_dev = usb_get_intfdata(interface);
 	struct htc_target *htc_handle = hif_dev->htc_handle;
 	int ret;
-	const struct firmware *fw;
+	const struct sysdata_file_desc fw_resume_desc = {
+		SYSDATA_DEFAULT_SYNC(ath9k_hif_usb_resume_fw, hif_dev),
+	};
 
 	ret = ath9k_hif_usb_alloc_urbs(hif_dev);
 	if (ret)
@@ -1325,15 +1346,8 @@ static int ath9k_hif_usb_resume(struct usb_interface *interface)
 
 	if (hif_dev->flags & HIF_USB_READY) {
 		/* request cached firmware during suspend/resume cycle */
-		ret = request_firmware(&fw, hif_dev->fw_name,
-				       &hif_dev->udev->dev);
-		if (ret)
-			goto fail_resume;
-
-		hif_dev->fw_data = fw->data;
-		hif_dev->fw_size = fw->size;
-		ret = ath9k_hif_usb_download_fw(hif_dev);
-		release_firmware(fw);
+		ret = sysdata_file_request("3826.arm", &fw_resume_desc,
+					   &hif_dev->udev->dev);
 		if (ret)
 			goto fail_resume;
 	} else {
-- 
2.3.2.209.gd67f9d5.dirty

[wireless-regdb] [RFC v1 10/12] ath9k_htc: use sysdata_file_request() and sysdata_file_request_async()

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/net/wireless/ath/ath9k/hif_usb.c | 62 +++++++++++++++++++-------------
 1 file changed, 38 insertions(+), 24 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 8e7153b..bc7591c 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -15,6 +15,7 @@
  */
 
 #include <asm/unaligned.h>
+#include <linux/sysdata.h>
 #include "htc.h"
 
 /* identify firmware images */
@@ -1079,7 +1080,8 @@ static void ath9k_hif_usb_firmware_fail(struct hif_device_usb *hif_dev)
 		device_unlock(parent);
 }
 
-static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void *context)
+static void ath9k_hif_usb_firmware_cb(const struct sysdata_file *fw,
+				      void *context)
 {
 	struct hif_device_usb *hif_dev = context;
 	int ret;
@@ -1115,7 +1117,7 @@ static void ath9k_hif_usb_firmware_cb(const struct firmware *fw, void *context)
 		goto err_htc_hw_init;
 	}
 
-	release_firmware(fw);
+	release_sysdata_file(fw);
 	hif_dev->flags |= HIF_USB_READY;
 	complete_all(&hif_dev->fw_done);
 
@@ -1126,7 +1128,7 @@ err_htc_hw_init:
 err_dev_init:
 	ath9k_htc_hw_free(hif_dev->htc_handle);
 err_dev_alloc:
-	release_firmware(fw);
+	release_sysdata_file(fw);
 err_fw:
 	ath9k_hif_usb_firmware_fail(hif_dev);
 }
@@ -1186,6 +1188,16 @@ static int send_eject_command(struct usb_interface *interface)
 	return 0;
 }
 
+int ath9k_hif_usb_probe_fw(struct hif_device_usb *hif_dev)
+{
+	const struct sysdata_file_desc fw_desc = {
+		SYSDATA_DEFAULT_ASYNC(ath9k_hif_usb_firmware_cb, hif_dev),
+	};
+
+	return sysdata_file_request_async(hif_dev->fw_name, &fw_desc,
+					  &hif_dev->udev->dev);
+}
+
 static int ath9k_hif_usb_probe(struct usb_interface *interface,
 			       const struct usb_device_id *id)
 {
@@ -1221,18 +1233,9 @@ static int ath9k_hif_usb_probe(struct usb_interface *interface,
 	else
 		hif_dev->fw_name = FIRMWARE_AR9271;
 
-	ret = request_firmware_nowait(THIS_MODULE, true, hif_dev->fw_name,
-				      &hif_dev->udev->dev, GFP_KERNEL,
-				      hif_dev, ath9k_hif_usb_firmware_cb);
-	if (ret) {
-		dev_err(&hif_dev->udev->dev,
-			"ath9k_htc: Async request for firmware %s failed\n",
-			hif_dev->fw_name);
+	ret = ath9k_hif_usb_probe_fw(hif_dev);
+	if (ret)
 		goto err_fw_req;
-	}
-
-	dev_info(&hif_dev->udev->dev, "ath9k_htc: Firmware %s requested\n",
-		 hif_dev->fw_name);
 
 	return 0;
 
@@ -1312,12 +1315,30 @@ static int ath9k_hif_usb_suspend(struct usb_interface *interface,
 	return 0;
 }
 
+static int ath9k_hif_usb_resume_fw(void *context,
+				   const struct sysdata_file *fw)
+{
+	struct hif_device_usb *hif_dev = context;
+	int ret;
+
+	hif_dev->fw_data = fw->data;
+	hif_dev->fw_size = fw->size;
+
+	ret = ath9k_hif_usb_download_fw(hif_dev);
+
+	release_sysdata_file(fw);
+
+	return ret;
+}
+
 static int ath9k_hif_usb_resume(struct usb_interface *interface)
 {
 	struct hif_device_usb *hif_dev = usb_get_intfdata(interface);
 	struct htc_target *htc_handle = hif_dev->htc_handle;
 	int ret;
-	const struct firmware *fw;
+	const struct sysdata_file_desc fw_resume_desc = {
+		SYSDATA_DEFAULT_SYNC(ath9k_hif_usb_resume_fw, hif_dev),
+	};
 
 	ret = ath9k_hif_usb_alloc_urbs(hif_dev);
 	if (ret)
@@ -1325,15 +1346,8 @@ static int ath9k_hif_usb_resume(struct usb_interface *interface)
 
 	if (hif_dev->flags & HIF_USB_READY) {
 		/* request cached firmware during suspend/resume cycle */
-		ret = request_firmware(&fw, hif_dev->fw_name,
-				       &hif_dev->udev->dev);
-		if (ret)
-			goto fail_resume;
-
-		hif_dev->fw_data = fw->data;
-		hif_dev->fw_size = fw->size;
-		ret = ath9k_hif_usb_download_fw(hif_dev);
-		release_firmware(fw);
+		ret = sysdata_file_request("3826.arm", &fw_resume_desc,
+					   &hif_dev->udev->dev);
 		if (ret)
 			goto fail_resume;
 	} else {
-- 
2.3.2.209.gd67f9d5.dirty


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

[RFC v1 11/12] iwlwifi: use sysdata_file_request() and sysdata_file_request_async()

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/net/wireless/iwlwifi/iwl-drv.c | 24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-drv.c b/drivers/net/wireless/iwlwifi/iwl-drv.c
index c7154ac..f20bda9 100644
--- a/drivers/net/wireless/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/iwlwifi/iwl-drv.c
@@ -65,6 +65,7 @@
 #include <linux/completion.h>
 #include <linux/dma-mapping.h>
 #include <linux/firmware.h>
+#include <linux/sysdata.h>
 #include <linux/module.h>
 #include <linux/vmalloc.h>
 
@@ -202,7 +203,7 @@ static int iwl_alloc_fw_desc(struct iwl_drv *drv, struct fw_desc *desc,
 	return 0;
 }
 
-static void iwl_req_fw_callback(const struct firmware *ucode_raw,
+static void iwl_req_fw_callback(const struct sysdata_file *ucode_raw,
 				void *context);
 
 #define UCODE_EXPERIMENTAL_INDEX	100
@@ -212,6 +213,9 @@ static int iwl_request_firmware(struct iwl_drv *drv, bool first)
 {
 	const char *name_pre = drv->cfg->fw_name_pre;
 	char tag[8];
+	const struct sysdata_file_desc fw_desc = {
+		SYSDATA_DEFAULT_ASYNC(iwl_req_fw_callback, drv),
+	};
 
 	if (first) {
 #ifdef CONFIG_IWLWIFI_DEBUG_EXPERIMENTAL_UCODE
@@ -256,9 +260,8 @@ static int iwl_request_firmware(struct iwl_drv *drv, bool first)
 				? "EXPERIMENTAL " : "",
 		       drv->firmware_name);
 
-	return request_firmware_nowait(THIS_MODULE, 1, drv->firmware_name,
-				       drv->trans->dev,
-				       GFP_KERNEL, drv, iwl_req_fw_callback);
+	return sysdata_file_request_async(drv->firmware_name, &fw_desc,
+					  drv->trans->dev);
 }
 
 struct fw_img_parsing {
@@ -453,7 +456,7 @@ static int iwl_set_ucode_capabilities(struct iwl_drv *drv, const u8 *data,
 }
 
 static int iwl_parse_v1_v2_firmware(struct iwl_drv *drv,
-				    const struct firmware *ucode_raw,
+				    const struct sysdata_file *ucode_raw,
 				    struct iwl_firmware_pieces *pieces)
 {
 	struct iwl_ucode_header *ucode = (void *)ucode_raw->data;
@@ -554,7 +557,7 @@ static int iwl_parse_v1_v2_firmware(struct iwl_drv *drv,
 }
 
 static int iwl_parse_tlv_firmware(struct iwl_drv *drv,
-				const struct firmware *ucode_raw,
+				const struct sysdata_file *ucode_raw,
 				struct iwl_firmware_pieces *pieces,
 				struct iwl_ucode_capabilities *capa)
 {
@@ -1051,7 +1054,8 @@ static void _iwl_op_mode_stop(struct iwl_drv *drv)
  * If loaded successfully, copies the firmware into buffers
  * for the card to fetch (via DMA).
  */
-static void iwl_req_fw_callback(const struct firmware *ucode_raw, void *context)
+static void iwl_req_fw_callback(const struct sysdata_file *ucode_raw,
+				void *context)
 {
 	struct iwl_drv *drv = context;
 	struct iwl_fw *fw = &drv->fw;
@@ -1210,7 +1214,7 @@ static void iwl_req_fw_callback(const struct firmware *ucode_raw, void *context)
 			IWL_MAX_STANDARD_PHY_CALIBRATE_TBL_SIZE;
 
 	/* We have our copies now, allow OS release its copies */
-	release_firmware(ucode_raw);
+	release_sysdata_file(ucode_raw);
 
 	mutex_lock(&iwlwifi_opmode_table_mtx);
 	if (fw->mvm_fw)
@@ -1262,7 +1266,7 @@ static void iwl_req_fw_callback(const struct firmware *ucode_raw, void *context)
 
  try_again:
 	/* try next, if any */
-	release_firmware(ucode_raw);
+	release_sysdata_file(ucode_raw);
 	if (iwl_request_firmware(drv, false))
 		goto out_unbind;
 	kfree(pieces);
@@ -1271,7 +1275,7 @@ static void iwl_req_fw_callback(const struct firmware *ucode_raw, void *context)
  out_free_fw:
 	IWL_ERR(drv, "failed to allocate pci memory\n");
 	iwl_dealloc_ucode(drv);
-	release_firmware(ucode_raw);
+	release_sysdata_file(ucode_raw);
  out_unbind:
 	kfree(pieces);
 	complete(&drv->request_firmware_complete);
-- 
2.3.2.209.gd67f9d5.dirty

[wireless-regdb] [RFC v1 11/12] iwlwifi: use sysdata_file_request() and sysdata_file_request_async()

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 drivers/net/wireless/iwlwifi/iwl-drv.c | 24 ++++++++++++++----------
 1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/iwlwifi/iwl-drv.c b/drivers/net/wireless/iwlwifi/iwl-drv.c
index c7154ac..f20bda9 100644
--- a/drivers/net/wireless/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/iwlwifi/iwl-drv.c
@@ -65,6 +65,7 @@
 #include <linux/completion.h>
 #include <linux/dma-mapping.h>
 #include <linux/firmware.h>
+#include <linux/sysdata.h>
 #include <linux/module.h>
 #include <linux/vmalloc.h>
 
@@ -202,7 +203,7 @@ static int iwl_alloc_fw_desc(struct iwl_drv *drv, struct fw_desc *desc,
 	return 0;
 }
 
-static void iwl_req_fw_callback(const struct firmware *ucode_raw,
+static void iwl_req_fw_callback(const struct sysdata_file *ucode_raw,
 				void *context);
 
 #define UCODE_EXPERIMENTAL_INDEX	100
@@ -212,6 +213,9 @@ static int iwl_request_firmware(struct iwl_drv *drv, bool first)
 {
 	const char *name_pre = drv->cfg->fw_name_pre;
 	char tag[8];
+	const struct sysdata_file_desc fw_desc = {
+		SYSDATA_DEFAULT_ASYNC(iwl_req_fw_callback, drv),
+	};
 
 	if (first) {
 #ifdef CONFIG_IWLWIFI_DEBUG_EXPERIMENTAL_UCODE
@@ -256,9 +260,8 @@ static int iwl_request_firmware(struct iwl_drv *drv, bool first)
 				? "EXPERIMENTAL " : "",
 		       drv->firmware_name);
 
-	return request_firmware_nowait(THIS_MODULE, 1, drv->firmware_name,
-				       drv->trans->dev,
-				       GFP_KERNEL, drv, iwl_req_fw_callback);
+	return sysdata_file_request_async(drv->firmware_name, &fw_desc,
+					  drv->trans->dev);
 }
 
 struct fw_img_parsing {
@@ -453,7 +456,7 @@ static int iwl_set_ucode_capabilities(struct iwl_drv *drv, const u8 *data,
 }
 
 static int iwl_parse_v1_v2_firmware(struct iwl_drv *drv,
-				    const struct firmware *ucode_raw,
+				    const struct sysdata_file *ucode_raw,
 				    struct iwl_firmware_pieces *pieces)
 {
 	struct iwl_ucode_header *ucode = (void *)ucode_raw->data;
@@ -554,7 +557,7 @@ static int iwl_parse_v1_v2_firmware(struct iwl_drv *drv,
 }
 
 static int iwl_parse_tlv_firmware(struct iwl_drv *drv,
-				const struct firmware *ucode_raw,
+				const struct sysdata_file *ucode_raw,
 				struct iwl_firmware_pieces *pieces,
 				struct iwl_ucode_capabilities *capa)
 {
@@ -1051,7 +1054,8 @@ static void _iwl_op_mode_stop(struct iwl_drv *drv)
  * If loaded successfully, copies the firmware into buffers
  * for the card to fetch (via DMA).
  */
-static void iwl_req_fw_callback(const struct firmware *ucode_raw, void *context)
+static void iwl_req_fw_callback(const struct sysdata_file *ucode_raw,
+				void *context)
 {
 	struct iwl_drv *drv = context;
 	struct iwl_fw *fw = &drv->fw;
@@ -1210,7 +1214,7 @@ static void iwl_req_fw_callback(const struct firmware *ucode_raw, void *context)
 			IWL_MAX_STANDARD_PHY_CALIBRATE_TBL_SIZE;
 
 	/* We have our copies now, allow OS release its copies */
-	release_firmware(ucode_raw);
+	release_sysdata_file(ucode_raw);
 
 	mutex_lock(&iwlwifi_opmode_table_mtx);
 	if (fw->mvm_fw)
@@ -1262,7 +1266,7 @@ static void iwl_req_fw_callback(const struct firmware *ucode_raw, void *context)
 
  try_again:
 	/* try next, if any */
-	release_firmware(ucode_raw);
+	release_sysdata_file(ucode_raw);
 	if (iwl_request_firmware(drv, false))
 		goto out_unbind;
 	kfree(pieces);
@@ -1271,7 +1275,7 @@ static void iwl_req_fw_callback(const struct firmware *ucode_raw, void *context)
  out_free_fw:
 	IWL_ERR(drv, "failed to allocate pci memory\n");
 	iwl_dealloc_ucode(drv);
-	release_firmware(ucode_raw);
+	release_sysdata_file(ucode_raw);
  out_unbind:
 	kfree(pieces);
 	complete(&drv->request_firmware_complete);
-- 
2.3.2.209.gd67f9d5.dirty


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [RFC v1 11/12] iwlwifi: use sysdata_file_request() and sysdata_file_request_async()

[Johannes Berg]

What's the point in these conversions? You're clearly not converting
*all* users so you could get rid of request_firmware(), so this is
pretty much pointless.

johannes

Re: [wireless-regdb] [RFC v1 11/12] iwlwifi: use sysdata_file_request() and sysdata_file_request_async()

[Johannes Berg]

What's the point in these conversions? You're clearly not converting
*all* users so you could get rid of request_firmware(), so this is
pretty much pointless.

johannes


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [RFC v1 11/12] iwlwifi: use sysdata_file_request() and sysdata_file_request_async()

[Luis R. Rodriguez]

On Wed, May 06, 2015 at 09:03:18AM +0200, Johannes Berg wrote:
> What's the point in these conversions? You're clearly not converting
> *all* users so you could get rid of request_firmware(), so this is
> pretty much pointless.

That is correct, as the cover letter stated these are just
examples of how one can use the new proposed extensible
API, the driver changes were just examples, it would
certainly be pointless and stupid to convert drivers
over.

  Luis

Re: [wireless-regdb] [RFC v1 11/12] iwlwifi: use sysdata_file_request() and sysdata_file_request_async()

[Luis R. Rodriguez]

On Wed, May 06, 2015 at 09:03:18AM +0200, Johannes Berg wrote:
> What's the point in these conversions? You're clearly not converting
> *all* users so you could get rid of request_firmware(), so this is
> pretty much pointless.

That is correct, as the cover letter stated these are just
examples of how one can use the new proposed extensible
API, the driver changes were just examples, it would
certainly be pointless and stupid to convert drivers
over.

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

[RFC v1 12/12] cfg80211: request for regulatory system data file

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

With sysdata_file_request_*() helpers in places we
don't need CRDA anymore, we can just request for the
regulatory file we need from within the kernel with
the kernel's configuration preferences for
cryptographic requirements.

-- this patch is incomplete still, it doesn't have
   any optional key preferences yet. This needs
   discussion.

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 net/wireless/Kconfig | 20 +++++++++++++
 net/wireless/reg.c   | 85 ++++++++++++++++++++++++++++++++++++++++++----------
 2 files changed, 89 insertions(+), 16 deletions(-)

diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 29c8675..1610d30 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -152,6 +152,26 @@ config CFG80211_DEBUGFS
 
 	  If unsure, say N.
 
+config CFG80211_REGDB_SYSDATA
+	default y
+	bool "Request binary regulatory database from userspace"
+	depends on CFG80211
+	---help---
+	  This allows cfg80211 to look for updates to the regulatory
+	  database from /lib/firmware/ without needing a userspace
+	  agent such as CRDA.
+
+	  You should say y.
+
+config CFG80211_REGDB_SYSDATA_SIGNED
+	default y
+	bool "Require the regulatory database to be digitally signed"
+	depends on CFG80211 && CFG80211_REGDB_SYSDATA
+	---help---
+	  This makes cfg80211 only trust signed regulatory database files.
+
+	  You should say y.
+
 config CFG80211_INTERNAL_REGDB
 	bool "use statically compiled regulatory rules database" if EXPERT
 	default n
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 48dfc7b..70a1be8 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1,21 +1,39 @@
 /*
- * Copyright 2002-2005, Instant802 Networks, Inc.
- * Copyright 2005-2006, Devicescape Software, Inc.
- * Copyright 2007	Johannes Berg <johannes@sipsolutions.net>
- * Copyright 2008-2011	Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
- * Copyright 2013-2014  Intel Mobile Communications GmbH
+ * Linux 802.11 regulatory
  *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
+ * Copyright 2015 Luis R. Rodriguez <mcgrof@do-not-panic.com>
  *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
- * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
- * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING.  If not, see
+ * http://www.gnu.org/licenses/.
+ *
+ * This file was previously licensed under the following license:
+ *    Copyright 2002-2005, Instant802 Networks, Inc.
+ *    Copyright 2005-2006, Devicescape Software, Inc.
+ *    Copyright 2007       Johannes Berg <johannes@sipsolutions.net>
+ *    Copyright 2008-2011  Luis R. Rodriguez <mcgrof@do-not-panic.com>
+ *    Copyright 2013-2014  Intel Mobile Communications GmbH
+ *
+ *    Permission to use, copy, modify, and/or distribute this software for any
+ *    purpose with or without fee is hereby granted, provided that the above
+ *    copyright notice and this permission notice appear in all copies.
+ *
+ *    THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ *    WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ *    MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ *    ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ *    WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ *    ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ *    OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
 
@@ -53,6 +71,7 @@
 #include <linux/nl80211.h>
 #include <linux/platform_device.h>
 #include <linux/moduleparam.h>
+#include <linux/sysdata.h>
 #include <net/cfg80211.h>
 #include "core.h"
 #include "reg.h"
@@ -73,6 +92,8 @@
  */
 #define REG_ENFORCE_GRACE_MS 60000
 
+const struct sysdata_file *regulatory_sysdata;
+
 /**
  * enum reg_request_treatment - regulatory request treatment
  *
@@ -3079,9 +3100,33 @@ bool regulatory_indoor_allowed(void)
 	return reg_is_indoor;
 }
 
+static void reg_sysdata_complete(const struct sysdata_file *sysdata,
+				      void *context)
+{
+	const char *reason = context;
+
+	pr_info("Processing regulatory data request from: %s", reason);
+
+	if (!sysdata) {
+		pr_info("no new regulatory data not available\n");
+		return;
+	}
+
+	if (sysdata->data) {
+		pr_info("XXX: sysdata for reguatory present: size: %d\n",
+		       (int) sysdata->size);
+	} else
+		pr_info("XXX: sysdata not present :(\n");
+
+	regulatory_sysdata = sysdata;
+}
+
 int __init regulatory_init(void)
 {
 	int err = 0;
+	const struct sysdata_file_desc sysdata_desc = {
+		SYSDATA_DEFAULT_ASYNC(reg_sysdata_complete, "initial boot"),
+	};
 
 	reg_pdev = platform_device_register_simple("regulatory", 0, NULL, 0);
 	if (IS_ERR(reg_pdev))
@@ -3120,7 +3165,13 @@ int __init regulatory_init(void)
 		regulatory_hint_user(ieee80211_regdom,
 				     NL80211_USER_REG_HINT_USER);
 
-	return 0;
+	err = sysdata_file_request_async("regulatory.bin",
+					 &sysdata_desc,
+					 &reg_pdev->dev);
+	if (err)
+		platform_device_unregister(reg_pdev);
+
+	return err;
 }
 
 void regulatory_exit(void)
@@ -3155,4 +3206,6 @@ void regulatory_exit(void)
 		list_del(&reg_request->list);
 		kfree(reg_request);
 	}
+
+	release_sysdata_file(regulatory_sysdata);
 }
-- 
2.3.2.209.gd67f9d5.dirty

[wireless-regdb] [RFC v1 12/12] cfg80211: request for regulatory system data file

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@suse.com>

With sysdata_file_request_*() helpers in places we
don't need CRDA anymore, we can just request for the
regulatory file we need from within the kernel with
the kernel's configuration preferences for
cryptographic requirements.

-- this patch is incomplete still, it doesn't have
   any optional key preferences yet. This needs
   discussion.

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 net/wireless/Kconfig | 20 +++++++++++++
 net/wireless/reg.c   | 85 ++++++++++++++++++++++++++++++++++++++++++----------
 2 files changed, 89 insertions(+), 16 deletions(-)

diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 29c8675..1610d30 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -152,6 +152,26 @@ config CFG80211_DEBUGFS
 
 	  If unsure, say N.
 
+config CFG80211_REGDB_SYSDATA
+	default y
+	bool "Request binary regulatory database from userspace"
+	depends on CFG80211
+	---help---
+	  This allows cfg80211 to look for updates to the regulatory
+	  database from /lib/firmware/ without needing a userspace
+	  agent such as CRDA.
+
+	  You should say y.
+
+config CFG80211_REGDB_SYSDATA_SIGNED
+	default y
+	bool "Require the regulatory database to be digitally signed"
+	depends on CFG80211 && CFG80211_REGDB_SYSDATA
+	---help---
+	  This makes cfg80211 only trust signed regulatory database files.
+
+	  You should say y.
+
 config CFG80211_INTERNAL_REGDB
 	bool "use statically compiled regulatory rules database" if EXPERT
 	default n
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 48dfc7b..70a1be8 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -1,21 +1,39 @@
 /*
- * Copyright 2002-2005, Instant802 Networks, Inc.
- * Copyright 2005-2006, Devicescape Software, Inc.
- * Copyright 2007	Johannes Berg <johannes@sipsolutions.net>
- * Copyright 2008-2011	Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
- * Copyright 2013-2014  Intel Mobile Communications GmbH
+ * Linux 802.11 regulatory
  *
- * Permission to use, copy, modify, and/or distribute this software for any
- * purpose with or without fee is hereby granted, provided that the above
- * copyright notice and this permission notice appear in all copies.
+ * Copyright 2015 Luis R. Rodriguez <mcgrof@do-not-panic.com>
  *
- * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
- * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
- * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
- * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
- * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
- * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; see the file COPYING.  If not, see
+ * http://www.gnu.org/licenses/.
+ *
+ * This file was previously licensed under the following license:
+ *    Copyright 2002-2005, Instant802 Networks, Inc.
+ *    Copyright 2005-2006, Devicescape Software, Inc.
+ *    Copyright 2007       Johannes Berg <johannes@sipsolutions.net>
+ *    Copyright 2008-2011  Luis R. Rodriguez <mcgrof@do-not-panic.com>
+ *    Copyright 2013-2014  Intel Mobile Communications GmbH
+ *
+ *    Permission to use, copy, modify, and/or distribute this software for any
+ *    purpose with or without fee is hereby granted, provided that the above
+ *    copyright notice and this permission notice appear in all copies.
+ *
+ *    THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ *    WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ *    MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ *    ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ *    WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ *    ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ *    OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
  */
 
 
@@ -53,6 +71,7 @@
 #include <linux/nl80211.h>
 #include <linux/platform_device.h>
 #include <linux/moduleparam.h>
+#include <linux/sysdata.h>
 #include <net/cfg80211.h>
 #include "core.h"
 #include "reg.h"
@@ -73,6 +92,8 @@
  */
 #define REG_ENFORCE_GRACE_MS 60000
 
+const struct sysdata_file *regulatory_sysdata;
+
 /**
  * enum reg_request_treatment - regulatory request treatment
  *
@@ -3079,9 +3100,33 @@ bool regulatory_indoor_allowed(void)
 	return reg_is_indoor;
 }
 
+static void reg_sysdata_complete(const struct sysdata_file *sysdata,
+				      void *context)
+{
+	const char *reason = context;
+
+	pr_info("Processing regulatory data request from: %s", reason);
+
+	if (!sysdata) {
+		pr_info("no new regulatory data not available\n");
+		return;
+	}
+
+	if (sysdata->data) {
+		pr_info("XXX: sysdata for reguatory present: size: %d\n",
+		       (int) sysdata->size);
+	} else
+		pr_info("XXX: sysdata not present :(\n");
+
+	regulatory_sysdata = sysdata;
+}
+
 int __init regulatory_init(void)
 {
 	int err = 0;
+	const struct sysdata_file_desc sysdata_desc = {
+		SYSDATA_DEFAULT_ASYNC(reg_sysdata_complete, "initial boot"),
+	};
 
 	reg_pdev = platform_device_register_simple("regulatory", 0, NULL, 0);
 	if (IS_ERR(reg_pdev))
@@ -3120,7 +3165,13 @@ int __init regulatory_init(void)
 		regulatory_hint_user(ieee80211_regdom,
 				     NL80211_USER_REG_HINT_USER);
 
-	return 0;
+	err = sysdata_file_request_async("regulatory.bin",
+					 &sysdata_desc,
+					 &reg_pdev->dev);
+	if (err)
+		platform_device_unregister(reg_pdev);
+
+	return err;
 }
 
 void regulatory_exit(void)
@@ -3155,4 +3206,6 @@ void regulatory_exit(void)
 		list_del(&reg_request->list);
 		kfree(reg_request);
 	}
+
+	release_sysdata_file(regulatory_sysdata);
 }
-- 
2.3.2.209.gd67f9d5.dirty


_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [PATCH v1 02/12] kernel: generalize module signing as system data signing

[David Howells]

Luis R. Rodriguez <mcgrof@do-not-panic.com> wrote:

> This generalizes the module signing code as helpers, we do
> this as we'll later re-use this same code for firmware and
> other system data signing.

I'm trying to move us to the use of PKCS#7 certificates as module signatures.
See here:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7

I would suggest you use this as a base.

Also, I would suggest, if you can manage it, either:

 (1) Keep the signature and the firmware blobs separate on disk for copyright
     and/or licensing purposes.

 (2) Put the firmware blob inside the PKCS#7 message as the embedded data.

David

Re: [wireless-regdb] [PATCH v1 02/12] kernel: generalize module signing as system data signing

[David Howells]

Luis R. Rodriguez <mcgrof@do-not-panic.com> wrote:

> This generalizes the module signing code as helpers, we do
> this as we'll later re-use this same code for firmware and
> other system data signing.

I'm trying to move us to the use of PKCS#7 certificates as module signatures.
See here:

	http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=modsign-pkcs7

I would suggest you use this as a base.

Also, I would suggest, if you can manage it, either:

 (1) Keep the signature and the firmware blobs separate on disk for copyright
     and/or licensing purposes.

 (2) Put the firmware blob inside the PKCS#7 message as the embedded data.

David

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [RFC v1 05/12] firmware: add firmware signature checking support

[David Howells]

Luis R. Rodriguez <mcgrof@do-not-panic.com> wrote:

> As with module signing, we do a very simple search for a
> particular string appended to the firmware. There's both a
> config option and a boot parameter which control whether we
> accept or fail with unsigned firmware and firmware that are
> signed with an unknown key.
> 
> If firmware signing is enabled, the kernel will be tainted
> if a firmware is loaded that is unsigned or has a signature
> for which we don't have the key.

I think you need to be careful storing the firmware blobs on disk with
signatures attached for two reasons:

 (1) There may be licensing/copyright issues on these blobs if you alter them.

 (2) Someone might try loading the modified blob without the signature being
     stripped - say someone runs an old kernel or copies the blob to a
     non-Linux system and tries to load it there.

Adding the signature to the blob upon loading might be less problematic, but
it still potentially suffers from (2) above.

If you switch to PKCS#7, you can also embed the blob inside the PKCS#7
message, so essentially the blob is unmodified and can be verified or
extracted by any suitable PKCS#7 tool.  This is more likely to get the
firmware rejected if the kernel isn't expecting it to be signed, I think.

I'm not sure how userspace actually passes the firmware blob to the kernel,
but I do think that if you can, you should pass the signature separately to
the blob.

With kernel modules this doesn't matter since modules are typically tied to a
single kernel version anyway.

David

Re: [wireless-regdb] [RFC v1 05/12] firmware: add firmware signature checking support

[David Howells]

Luis R. Rodriguez <mcgrof@do-not-panic.com> wrote:

> As with module signing, we do a very simple search for a
> particular string appended to the firmware. There's both a
> config option and a boot parameter which control whether we
> accept or fail with unsigned firmware and firmware that are
> signed with an unknown key.
> 
> If firmware signing is enabled, the kernel will be tainted
> if a firmware is loaded that is unsigned or has a signature
> for which we don't have the key.

I think you need to be careful storing the firmware blobs on disk with
signatures attached for two reasons:

 (1) There may be licensing/copyright issues on these blobs if you alter them.

 (2) Someone might try loading the modified blob without the signature being
     stripped - say someone runs an old kernel or copies the blob to a
     non-Linux system and tries to load it there.

Adding the signature to the blob upon loading might be less problematic, but
it still potentially suffers from (2) above.

If you switch to PKCS#7, you can also embed the blob inside the PKCS#7
message, so essentially the blob is unmodified and can be verified or
extracted by any suitable PKCS#7 tool.  This is more likely to get the
firmware rejected if the kernel isn't expecting it to be signed, I think.

I'm not sure how userspace actually passes the firmware blob to the kernel,
but I do think that if you can, you should pass the signature separately to
the blob.

With kernel modules this doesn't matter since modules are typically tied to a
single kernel version anyway.

David

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [RFC v1 05/12] firmware: add firmware signature checking support

[Luis R. Rodriguez]

On Wed, May 6, 2015 at 9:57 AM, David Howells <dhowells@redhat.com> wrote:
> I'm not sure how userspace actually passes the firmware blob to the kernel,
> but I do think that if you can, you should pass the signature separately to
> the blob.

Thanks yeah that is what I was hoping we'd prefer to end up doing.
Will look at your tree and see if I can base my work on that now.

 Luis

Re: [wireless-regdb] [RFC v1 05/12] firmware: add firmware signature checking support

[Luis R. Rodriguez]

On Wed, May 6, 2015 at 9:57 AM, David Howells <dhowells@redhat.com> wrote:
> I'm not sure how userspace actually passes the firmware blob to the kernel,
> but I do think that if you can, you should pass the signature separately to
> the blob.

Thanks yeah that is what I was hoping we'd prefer to end up doing.
Will look at your tree and see if I can base my work on that now.

 Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb

Re: [RFC v1 05/12] firmware: add firmware signature checking support

[Luis R. Rodriguez]

On Wed, May 6, 2015 at 9:57 AM, David Howells <dhowells@redhat.com> wrote:
> I'm not sure how userspace actually passes the firmware blob to the kernel,
> but I do think that if you can, you should pass the signature separately to
> the blob.

Thanks yeah that is what I was hoping we'd prefer to end up doing.
Will look at your tree and see if I can base my work on that now.

 Luis

Re: [RFC v1 00/12] kernel/firmware/wireless: firmware digital signature checks

[Luis R. Rodriguez]

On Tue, May 05, 2015 at 05:44:18PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
>   * first set: [1-4] few fixes and core changes in order to consider digital
>     firmware signature support. Please consider these for integration. Patch
>     2 generalizes module signing as system data signing and can very likely
>     just be ignored unles the second set seems more reasonable to start
>     considering. One of these goes as a stable fix.

Rusty, based on feedback only one patch is relevant for upstream consideration
then on your end:

  1  - kernel/params.c: export param_ops_bool_enable_only                                                                                                                       

Ming, as for firmware_class, this patch should be reviewed and
considered for upstream consideration:

  4  - firmware: fix possible use after free on name on asynchronous request 

The patches are orthogonal to each other so they can be considered
separately, and can go in through separate trees.

  Luis

Re: [wireless-regdb] [RFC v1 00/12] kernel/firmware/wireless: firmware digital signature checks

[Luis R. Rodriguez]

On Tue, May 05, 2015 at 05:44:18PM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
> 
>   * first set: [1-4] few fixes and core changes in order to consider digital
>     firmware signature support. Please consider these for integration. Patch
>     2 generalizes module signing as system data signing and can very likely
>     just be ignored unles the second set seems more reasonable to start
>     considering. One of these goes as a stable fix.

Rusty, based on feedback only one patch is relevant for upstream consideration
then on your end:

  1  - kernel/params.c: export param_ops_bool_enable_only                                                                                                                       

Ming, as for firmware_class, this patch should be reviewed and
considered for upstream consideration:

  4  - firmware: fix possible use after free on name on asynchronous request 

The patches are orthogonal to each other so they can be considered
separately, and can go in through separate trees.

  Luis

_______________________________________________
wireless-regdb mailing list
wireless-regdb@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/wireless-regdb