| Message ID | 20180511215250.GJ27853@wotan.suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, 2018-05-11 at 21:52 +0000, Luis R. Rodriguez wrote: > On Fri, May 11, 2018 at 01:00:26AM -0400, Mimi Zohar wrote: > > On Thu, 2018-05-10 at 23:26 +0000, Luis R. Rodriguez wrote: > > > On Wed, May 09, 2018 at 10:00:58PM -0400, Mimi Zohar wrote: > > > > On Wed, 2018-05-09 at 23:48 +0000, Luis R. Rodriguez wrote: > > > > > On Wed, May 09, 2018 at 06:06:57PM -0400, Mimi Zohar wrote: > > > > > > > > > > > > Yes, writing regdb as a micro/mini LSM sounds reasonable. The LSM > > > > > > > > would differentiate between other firmware and the regulatory.db based > > > > > > > > on the firmware's pathname. > > > > > > > > > > > > > > If that is the only way then it would be silly to do the mini LSM as all > > > > > > > calls would have to have the check. A special LSM hook for just the > > > > > > > regulatory db also doesn't make much sense. > > > > > > > > > > > > All calls to request_firmware() are already going through this LSM > > > > > > hook. I should have said, it would be based on both READING_FIRMWARE > > > > > > and the firmware's pathname. > > > > > > > > > > Yes, but it would still be a strcmp() computation added for all > > > > > READING_FIRMWARE. In that sense, the current arrangement is only open coding the > > > > > signature verification for the regulatory.db file. One way to avoid this would > > > > > be to add an LSM specific to the regulatory db > > > > > > > > Casey already commented on this suggestion. > > > > > > Sorry but I must have missed this, can you send me the email or URL where he did that? > > > I never got a copy of that email I think. > > > > My mistake. I've posted similar patches for kexec_load and for the > > firmware sysfs fallback, both call security_kernel_read_file(). > > Casey's comment was in regards to kexec_load[1], not for the sysfs > > fallback mode. Here's the link to the most recent version of the > > kexec_load patches.[2] > > > > [1] http://kernsec.org/pipermail/linux-security-module-archive/2018-May/006690.html > > [2] http://kernsec.org/pipermail/linux-security-module-archive/2018-May/006854.html > > It seems I share Eric's concern on these threads are over general architecture, > below some notes which I think may help for the long term on that regards. > > In the firmware_loader case we have *one* subsystem which as open coded firmware > signing -- the wireless subsystem open codes firmware verification by doing two > request_firmware() calls, one for the regulatory.bin and one for regulatory.bin.p7s, > and then it does its own check. In this patch set you suggested adding > a new READING_FIRMWARE_REGULATORY_DB. But your first patch in the series also > adds READING_FIRMWARE_FALLBACK for the fallback case where we enable use of > the old syfs loading facility. > > My concerns are two fold for this case: > > a) This would mean adding a new READING_* ID tag per any kernel mechanism which open > codes its own signature verification scheme. Yes, that's true. In order to differentiate between different methods, there needs to be some way of differentiating between them. > > b) The way it was implemented was to do (just showing > READING_FIRMWARE_REGULATORY_DB here): The purpose for READING_FIRMWARE_REGULATORY_DB is different than for adding enumerations for other firmware verification methods (eg. fallback sysfs). In this case, both IMA-appraisal and REGDB are being called to verify the firmware signature. Adding READING_FIRMWARE_REGULATORY_DB was in order to coordinate between them. continued below ... > > diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c > index eb34089e4299..d7cdf04a8681 100644 > --- a/drivers/base/firmware_loader/main.c > +++ b/drivers/base/firmware_loader/main.c > @@ -318,6 +318,11 @@ fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv) > break; > } > > +#ifdef CONFIG_CFG80211_REQUIRE_SIGNED_REGDB > + if ((strcmp(fw_priv->fw_name, "regulatory.db") == 0) || > + (strcmp(fw_priv->fw_name, "regulatory.db.p7s") == 0)) > + id = READING_FIRMWARE_REGULATORY_DB; > +#endif > fw_priv->size = 0; > rc = kernel_read_file_from_path(path, &fw_priv->data, &size, > msize, id); > > This is eye-soring, and in turn would mean adding yet more #ifdefs for any > code on the kernel which open codes other firmware signing efforts with > its own kconfig... Agreed, adding ifdef's is ugly. As previously discussed, this code will be removed. To coordinate the signature verification, at build time either regdb or IMA-appraisal firmware will be enabled. At runtime, in the case that regdb is enabled and a custom policy requires IMA-appraisal firmware signature verification, then both signature verification methods will verify the signatures. If either fails, then the signature verification will fail. > I gather from reading the threads above that Eric's concerns are the re-use of > an API for security to read files for something which is really not a file, but > a binary blob of some sort and Casey's rebuttal is adding more hooks for small > things is a bad idea. > > In light of all this I'll say that the concerns Eric has are unfortunately > too late, that ship has sailed eons ago. The old non-fd API for module loading > init_module() calls security_kernel_read_file(NULL, READING_MODULE). Your > patch in this series adds security_kernel_read_file(NULL, READING_FIRMWARE_FALLBACK) > for the old syfs loading facility. It goes back even farther than that. Commit 2e72d51 ("security: introduce kernel_module_from_file hook") introduced calling security_kernel_module_from_file() in copy_module_from_user(). Commit a1db74209483 ("module: replace copy_module_from_fd with kernel version") replaced it with the call to security_kernel_read_file(). > So in this regard, I think we have no other option but what you suggested, to > add a wrapper, say a security_kernel_read_blob() wrapper that calls > security_kernel_read_file(NULL, id); and make the following legacy calls use > it: > > o kernel/module.c for init_module() > o kexec_load() > o firmware loader sysfs facility > > I think its fair then to add a new READING entry per functionality here > *but* with the compromise that we *document* that such interfaces are > discouraged, in preference for interfaces where at least the fd can be > captured some how. This should hopefully put a stop gap to such interfaces. Thanks! Eric, are you on board with this? > Then as for my concern on extending and adding new READING_* ID tags > for other future open-coded firmware calls, since: > > a) You seem to be working on a CONFIG_IMA_APPRAISE_FIRMWARE which would > enable similar functionality as firmware signing but in userspace. There are a number of different builtin policies. The "secure_boot" builtin policy enables file signature verification for firmware, kernel modules, kexec'ed image, and the IMA policy, but builtin policies are enabled on the boot command line. There are two problems: - there's no way of configuring a builtin policy to verify firmware signatures. - CONFIG_IMA_APPRAISE is not fine enough grained. The CONFIG_IMA_APPRAISE_FIRMWARE will be a Kconfig option. Similar Kconfig options will require kernel modules, kexec'ed image, and the IMA policy to be signed. With this, option "d", below, will be possible. > b) CONFIG_CFG80211_REQUIRE_SIGNED_REGDB was added to replace needing > CRDA, with an in-kernel interface. CRDA just did a signature check on > the regulatory.bin prior to tossing regulatory data over the kernel. > > c) We've taken a position to *not* implement generic firmware singing > upstream in light of the fact that UEFI has pushed hw manufacturers > to implement FW singing in hardware, and for devices outside of these > we're happy to suggest IMA use. There are a number of reasons that the kernel should be verifying firmware signatures (eg. requiring a specific version of the firmware, that was locally signed). > d) It may be possible to have CONFIG_CFG80211_REQUIRE_SIGNED_REGDB > depend on !CONFIG_IMA_APPRAISE_FIRMWARE this way we'd take a policy > that CONFIG_IMA_APPRAISE_FIRMWARE replaces in-kernel open coded > firmware singing facilities > > Then I think it makes sense to adapt a policy of being *very careful* allowing > future open coded firmware signing efforts such as > CONFIG_CFG80211_REQUIRE_SIGNED_REGDB, and recommend folks to do work for things > like this through IMA with CONFIG_IMA_APPRAISE_FIRMWARE. This would limit our > needs to extend READING_* ID tags for new open coded firmwares. > > Then as for the eye-sore you added for CONFIG_CFG80211_REQUIRE_SIGNED_REGDB, > in light of all this, I accept we have no other way to deal with it but with > #ifdefs.. however it could be dealt with, as helpers where if > CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is not set we just set the id to > READING_FIRMWARE, ie, just keep the #ifdefs out of the actual code we read. Assuming you agree with either REGDB or IMA-appraisal firmware being configured at build, but allowing a custom policy to require firmware signature verification based on IMA-appraisal at runtime, so that both REGDB and IMA-appraisal firmware signature verification methods are required, then the REGDB ifdef's can be removed. > Perhaps it makes sense to throw this check into the helper: > > /* Already populated data member means we're loading into a buffer */ > if (fw_priv->data) { > id = READING_FIRMWARE_PREALLOC_BUFFER; > msize = fw_priv->allocated_size; > } Thanks, this looks good. What IMA-appraisal should do with READING_FIRMWARE_PREALLOC_BUFFER still needs to be determined. > PS: the work Alexei is doing with fork_usermode_blob() may sound similar > to the above legacy cases, but as I have noted before -- it already uses > an LSM hook to vet the data loaded as the data gets loaded as module. Thank you for the clarification. Mimi
On Mon, May 14, 2018 at 08:58:12AM -0400, Mimi Zohar wrote: > On Fri, 2018-05-11 at 21:52 +0000, Luis R. Rodriguez wrote: > > diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c > > index eb34089e4299..d7cdf04a8681 100644 > > --- a/drivers/base/firmware_loader/main.c > > +++ b/drivers/base/firmware_loader/main.c > > @@ -318,6 +318,11 @@ fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv) > > break; > > } > > > > +#ifdef CONFIG_CFG80211_REQUIRE_SIGNED_REGDB > > + if ((strcmp(fw_priv->fw_name, "regulatory.db") == 0) || > > + (strcmp(fw_priv->fw_name, "regulatory.db.p7s") == 0)) > > + id = READING_FIRMWARE_REGULATORY_DB; > > +#endif > > fw_priv->size = 0; > > rc = kernel_read_file_from_path(path, &fw_priv->data, &size, > > msize, id); > > > > This is eye-soring, and in turn would mean adding yet more #ifdefs for any > > code on the kernel which open codes other firmware signing efforts with > > its own kconfig... > > Agreed, adding ifdef's is ugly. As previously discussed, this code > will be removed. > > To coordinate the signature verification, at build time either regdb > or IMA-appraisal firmware will be enabled. But not both, right? > At runtime, in the case > that regdb is enabled and a custom policy requires IMA-appraisal > firmware signature verification, then both signature verification > methods will verify the signatures. If either fails, then the > signature verification will fail. OK so you're saying that if CONFIG_IMA_APPRAISE_FIRMWARE is disabled you can still end up with CONFIG_CFG80211_REQUIRE_SIGNED_REGDB as enabled *and* a custom policy which requires IMA-appraisal for the certain firmware signature verifications? > > Then as for my concern on extending and adding new READING_* ID tags > > for other future open-coded firmware calls, since: > > > > a) You seem to be working on a CONFIG_IMA_APPRAISE_FIRMWARE which would > > enable similar functionality as firmware signing but in userspace. > > There are a number of different builtin policies. The "secure_boot" > builtin policy enables file signature verification for firmware, > kernel modules, kexec'ed image, and the IMA policy, but builtin > policies are enabled on the boot command line. > > There are two problems: > - there's no way of configuring a builtin policy to verify firmware > signatures. I'm not too familiar with IMA however it sounds like you can extend the IMA built-in policy on the boot command line. If so I'll note MODULE_FIRMWARE() macro is typically used to annotate firmware description -- not all drivers use this though for a few reasons, for instance once is that some names are constructed dynamically at run time. Consider how some drivers rev firmware with versions, and as they do this they want to keep certain features only for certain firmware versions. Despite this lack of a direct 1-1 mapping for all firmwares needed, I *believe* one current use case for this macro is to extract required firmwares needed on early boot so they can be stashed into the initramfs if you have these modules enabled on the initramfs. Dracut folks can confirm but -- dracut *seems* broken then given the semantic gap I mentioned above. dracut-init.sh: for _fw in $(modinfo -k $kernel -F firmware $1 2>/dev/null); do If I read this correctly this just complains if the firmware file is missing if the module is installed on initramfs and the firmware file is not present. If so we have a current semantic gap and modules with dynamic names are not handled. And its unclear which modules would be affected. This is a not a big issue for dracut though since not all drivers strive to be included on initramfs, unless their storage I suppose -- not sure how common these storage drivers are for initramfs with dynamic firmware names which do *not* use MODULE_FIRMWARE(). While the idea of MODULE_FIRMWARE() may need to be given some love or adjusted to incorporate globs / regexps to fix this existing gap, or we come up with something more reliable, if fixed, it in theory could end up being re-used to enable you to extract and build policies for firmware signing at build time... > - CONFIG_IMA_APPRAISE is not fine enough grained. > > The CONFIG_IMA_APPRAISE_FIRMWARE will be a Kconfig option. Similar > Kconfig options will require kernel modules, kexec'ed image, and the > IMA policy to be signed. Sure, it is still unclear to me if CONFIG_IMA_APPRAISE_FIRMWARE will be doing firmware verification in userspace or in the kernel. > With this, option "d", below, will be possible. nit: To be clear I was not stating options, I was stating premises to justify my recommendations. > > b) CONFIG_CFG80211_REQUIRE_SIGNED_REGDB was added to replace needing > > CRDA, with an in-kernel interface. CRDA just did a signature check on > > the regulatory.bin prior to tossing regulatory data over the kernel. > > > > c) We've taken a position to *not* implement generic firmware singing > > upstream in light of the fact that UEFI has pushed hw manufacturers > > to implement FW singing in hardware, and for devices outside of these > > we're happy to suggest IMA use. > > There are a number of reasons that the kernel should be verifying > firmware signatures (eg. requiring a specific version of the firmware, > that was locally signed). Oh I agree, Linux enterprise distributions also have a strong reason to have this, so that for instance we only trust and run vendor-approved signed firmware. Otherwise the driver should reject the firmware. Every now and then enterprise distros may run into cases were certain customers may run oddball firmwares, and its unclear if we expect proper functionality with that firmware. Having some form of firmware signing would help with this pipeline, but this is currently dealt with at the packaging, and noting other than logs ensures the driver is using an intended firmware. But these needs *IMHO* have not been enough to push to generalize a kernel firmware signing facility. If CONFIG_IMA_APPRAISE_FIRMWARE is going to provide this functionality somehow I'm happy to hear it. > > d) It may be possible to have CONFIG_CFG80211_REQUIRE_SIGNED_REGDB > > depend on !CONFIG_IMA_APPRAISE_FIRMWARE this way we'd take a policy > > that CONFIG_IMA_APPRAISE_FIRMWARE replaces in-kernel open coded > > firmware singing facilities > > > > Then I think it makes sense to adapt a policy of being *very careful* allowing > > future open coded firmware signing efforts such as > > CONFIG_CFG80211_REQUIRE_SIGNED_REGDB, and recommend folks to do work for things > > like this through IMA with CONFIG_IMA_APPRAISE_FIRMWARE. This would limit our > > needs to extend READING_* ID tags for new open coded firmwares. > > > > Then as for the eye-sore you added for CONFIG_CFG80211_REQUIRE_SIGNED_REGDB, > > in light of all this, I accept we have no other way to deal with it but with > > #ifdefs.. however it could be dealt with, as helpers where if > > CONFIG_CFG80211_REQUIRE_SIGNED_REGDB is not set we just set the id to > > READING_FIRMWARE, ie, just keep the #ifdefs out of the actual code we read. > > Assuming you agree with either REGDB or IMA-appraisal firmware being > configured at build, but allowing a custom policy to require firmware > signature verification based on IMA-appraisal at runtime, so that both > REGDB and IMA-appraisal firmware signature verification methods are > required, then the REGDB ifdef's can be removed. Yes, this sounds fine. But I'm also saying we can *live* with them if they are wrapped in #ifdefs with functions sot hat when something is not required they are a no-op. Ideally if we could avoid this it would be great and it seems you're saying its possible. Keeping the #ifdefs with function wrappers would make sense as a trade-off if we really are going to make toss firmware under CONFIG_IMA_APPRAISE_FIRMWARE and want to review carefully the addition of new open coded firmware solutions (as the regulatory.db work). Luis
On Mon, 2018-05-14 at 19:28 +0000, Luis R. Rodriguez wrote: [...] > > At runtime, in the case > > that regdb is enabled and a custom policy requires IMA-appraisal > > firmware signature verification, then both signature verification > > methods will verify the signatures. If either fails, then the > > signature verification will fail. > > OK so you're saying that if CONFIG_IMA_APPRAISE_FIRMWARE is disabled you can > still end up with CONFIG_CFG80211_REQUIRE_SIGNED_REGDB as enabled *and* a > custom policy which requires IMA-appraisal for the certain firmware signature > verifications? Right > > There are two problems: > > - there's no way of configuring a builtin policy to verify firmware > > signatures. > > I'm not too familiar with IMA however it sounds like you can extend the IMA > built-in policy on the boot command line. No, there are a couple of policies predefined in the kernel that can be loaded by specifying them on the boot command line. A custom policy can be loaded later. Only after specifying a policy on the boot command line or loading a custom policy, does IMA do anything. > > - CONFIG_IMA_APPRAISE is not fine enough grained. > > > > The CONFIG_IMA_APPRAISE_FIRMWARE will be a Kconfig option. Similar > > Kconfig options will require kernel modules, kexec'ed image, and the > > IMA policy to be signed. > > Sure, it is still unclear to me if CONFIG_IMA_APPRAISE_FIRMWARE will be > doing firmware verification in userspace or in the kernel. The kernel is verifying signatures. > > There are a number of reasons that the kernel should be verifying > > firmware signatures (eg. requiring a specific version of the firmware, > > that was locally signed). > > Oh I agree, Linux enterprise distributions also have a strong reason to > have this, so that for instance we only trust and run vendor-approved > signed firmware. Otherwise the driver should reject the firmware. Every > now and then enterprise distros may run into cases were certain customers > may run oddball firmwares, and its unclear if we expect proper functionality > with that firmware. Having some form of firmware signing would help with > this pipeline, but this is currently dealt with at the packaging, and > noting other than logs ensures the driver is using an intended firmware. > But these needs *IMHO* have not been enough to push to generalize a kernel > firmware signing facility. In order for IMA-appraisal to verify firmware signatures, the signatures need to be distributed with the firmware. Perhaps this will be enough of an incentive for distros to start including firmware signatures in the packages. > If CONFIG_IMA_APPRAISE_FIRMWARE is going to provide this functionality somehow > I'm happy to hear it. The functionality has been there since commit 5a9196d ("ima: add support for measuring and appraising firmware"). The security_kernel_fw_from_file() hook was later replaced with the generic security_kernel_read_file() hook. Mimi
On Mon, May 14, 2018 at 10:02:31PM -0400, Mimi Zohar wrote: > On Mon, 2018-05-14 at 19:28 +0000, Luis R. Rodriguez wrote: > > > - CONFIG_IMA_APPRAISE is not fine enough grained. > > > > > > The CONFIG_IMA_APPRAISE_FIRMWARE will be a Kconfig option. Similar > > > Kconfig options will require kernel modules, kexec'ed image, and the > > > IMA policy to be signed. > > > > Sure, it is still unclear to me if CONFIG_IMA_APPRAISE_FIRMWARE will be > > doing firmware verification in userspace or in the kernel. > > The kernel is verifying signatures. > > > > There are a number of reasons that the kernel should be verifying > > > firmware signatures (eg. requiring a specific version of the firmware, > > > that was locally signed). > > > > Oh I agree, Linux enterprise distributions also have a strong reason to > > have this, so that for instance we only trust and run vendor-approved > > signed firmware. Otherwise the driver should reject the firmware. Every > > now and then enterprise distros may run into cases were certain customers > > may run oddball firmwares, and its unclear if we expect proper functionality > > with that firmware. Having some form of firmware signing would help with > > this pipeline, but this is currently dealt with at the packaging, and > > noting other than logs ensures the driver is using an intended firmware. > > But these needs *IMHO* have not been enough to push to generalize a kernel > > firmware signing facility. > > In order for IMA-appraisal to verify firmware signatures, the > signatures need to be distributed with the firmware. Perhaps this > will be enough of an incentive for distros to start including firmware > signatures in the packages. Best to poke the maintainers about that... We have been sending mixed messages about firmware signing over years now. Josh, heads up the new one is we can do firmware signing through IMA future CONFIG_IMA_APPRAISE_FIRMWARE. I'll bounce you a few emails related to this. > > If CONFIG_IMA_APPRAISE_FIRMWARE is going to provide this functionality somehow > > I'm happy to hear it. > > The functionality has been there since commit 5a9196d ("ima: add > support for measuring and appraising firmware"). The > security_kernel_fw_from_file() hook was later replaced with the > generic security_kernel_read_file() hook. Groovy, its unclear from the code on that commit how this is done, so I suppose I need to study this a bit more. Josh, do you grok it? Luis
On Mon, May 14, 2018 at 11:27 PM Luis R. Rodriguez <mcgrof@kernel.org> wrote: > On Mon, May 14, 2018 at 10:02:31PM -0400, Mimi Zohar wrote: > > On Mon, 2018-05-14 at 19:28 +0000, Luis R. Rodriguez wrote: > > > > - CONFIG_IMA_APPRAISE is not fine enough grained. > > > > > > > > The CONFIG_IMA_APPRAISE_FIRMWARE will be a Kconfig option. Similar > > > > Kconfig options will require kernel modules, kexec'ed image, and the > > > > IMA policy to be signed. > > > > > > Sure, it is still unclear to me if CONFIG_IMA_APPRAISE_FIRMWARE will be > > > doing firmware verification in userspace or in the kernel. > > > > The kernel is verifying signatures. > > > > > > There are a number of reasons that the kernel should be verifying > > > > firmware signatures (eg. requiring a specific version of the firmware, > > > > that was locally signed). > > > > > > Oh I agree, Linux enterprise distributions also have a strong reason to > > > have this, so that for instance we only trust and run vendor-approved > > > signed firmware. Otherwise the driver should reject the firmware. Every > > > now and then enterprise distros may run into cases were certain customers > > > may run oddball firmwares, and its unclear if we expect proper functionality > > > with that firmware. Having some form of firmware signing would help with > > > this pipeline, but this is currently dealt with at the packaging, and > > > noting other than logs ensures the driver is using an intended firmware. > > > But these needs *IMHO* have not been enough to push to generalize a kernel > > > firmware signing facility. > > > > In order for IMA-appraisal to verify firmware signatures, the > > signatures need to be distributed with the firmware. Perhaps this > > will be enough of an incentive for distros to start including firmware > > signatures in the packages. > Best to poke the maintainers about that... We have been sending mixed messages > about firmware signing over years now. Josh, heads up the new one is we can > do firmware signing through IMA future CONFIG_IMA_APPRAISE_FIRMWARE. I'll > bounce you a few emails related to this. > > > If CONFIG_IMA_APPRAISE_FIRMWARE is going to provide this functionality somehow > > > I'm happy to hear it. > > > > The functionality has been there since commit 5a9196d ("ima: add > > support for measuring and appraising firmware"). The > > security_kernel_fw_from_file() hook was later replaced with the > > generic security_kernel_read_file() hook. > Groovy, its unclear from the code on that commit how this is done, so I > suppose I need to study this a bit more. Josh, do you grok it? I haven't looked to be honest. I don't do much in the way of kernel maintenance on the distro side any longer. You already have David copied and I've added Justin Forbes and Laura Abbott to cover Fedora. One aspect that was always a concern to some is whether the firmware files were modified directly to have the signature attached to them. That may run afoul of the "no modification" license that most blobs are shipped under. Does IMA have the signatures for the files stored in xattrs or in some other detached manner? josh
On Tue, 2018-05-15 at 08:32 -0400, Josh Boyer wrote: > One aspect that was always a concern to some is whether the firmware files > were modified directly to have the signature attached to them. That may > run afoul of the "no modification" license that most blobs are shipped > under. Does IMA have the signatures for the files stored in xattrs or in > some other detached manner? They're stored as xattrs. RPM has support for including file signatures in the RPM header. Mimi
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c index eb34089e4299..d7cdf04a8681 100644 --- a/drivers/base/firmware_loader/main.c +++ b/drivers/base/firmware_loader/main.c @@ -318,6 +318,11 @@ fw_get_filesystem_firmware(struct device *device, struct fw_priv *fw_priv) break; } +#ifdef CONFIG_CFG80211_REQUIRE_SIGNED_REGDB + if ((strcmp(fw_priv->fw_name, "regulatory.db") == 0) || + (strcmp(fw_priv->fw_name, "regulatory.db.p7s") == 0)) + id = READING_FIRMWARE_REGULATORY_DB; +#endif fw_priv->size = 0; rc = kernel_read_file_from_path(path, &fw_priv->data, &size, msize, id);