Re: [PATCH 3/6] firmware: differentiate between signed regulatory.db and other firmware

[Luis R. Rodriguez]

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