[PATCH v2 0/5] firmware_class: extensible firmware API

[Luis R. Rodriguez]

From: "Luis R. Rodriguez" <mcgrof@xxxxxxxx>

This v2 series pushes together a few simple code shifts me and David
worked on with a new extensible firmware API. I have bundled these changes
together as in my last v1 series [0] it was not clear why the first simple
set of changes were being made, and I had sent out the extensible firmware
API only as an RFC and separately. I've bundled these two together, this should
make it clearer now why we made the first set of changes, the last patch is the
meat of the work to consider and review here. Its important to realize that
this series does not include firmware signing support. The exact architecture
for that is still being discussed -- if we don't all agree on the exact
architecture of firmware signing through mailing list discussions one
possibility is to just discuss it as one of the topics for the upcoming kernel
summit.

Now, regardless of the outcome of the exact architecture and design of firmware
signing -- a few thing are clear though:

1) we keep extending the firmware API as we come up with more needs, when
   we do this it means we have a series of unnecessary collateral evolutions
   on drivers... 

2) the user mode helper code needs to die off and although some distributions
   are now disabling support for it and systemd ripped out support
   for it, Josh Boyer recently noted that drivers other than dell-rbu
   now also select FW_LOADER_USER_HELPER_FALLBACK [1]... we should
   really just compartamentalize such use and phase that out slowly.

The extensible firmware API then is being introduced both as a stepping stone
to expected changes to the firmware API for Linux firmware signing support and
as a way for us to phase out the user mode helper.

My original approach to firmware signing was to support firmware signing
behind the scenes automatically for all drivers when enabled via Kconfig,
with one default key -- similar to how module signing support works. In this
original design it was only a side consideration to support custom keys for
firmware signing, for instance I had envisioned that we could replace CRDA
with a simple firmware request call with our own custom 802.11 key
requirements, which would be orthogonal to what distributions decide for
"general firmware signing". Upon review though those who have expressed
interest in firmware signing have stated interest to be able to specify their
own driver key signing criteria from the start. If we end up requiring key
requirements to *always* be specified we'll essentially be extending the
number of arguments to the firmware API from the start. Instead of having
*all* drivers be modified that use the old firmware API, or adding yet another
new call, an extensible firmware API would enable only changes to be made for
drivers that do want to explicitly opt-in for support for firmware signing,
with an added bonus of also avoiding the user mode helper, and enabling this
new API to be easily extensible in the future without other collateral
evolutions.

[0] http://lkml.kernel.org/r/1438725604-22795-1-git-send-email-mcgrof@xxxxxxxxxxxxxxxx
[1] http://lkml.kernel.org/r/CA+5PVA6toGj5iboTgK5Casy9vUAQC8SXYWKEx+ojwC51UEV0HA@xxxxxxxxxxxxxx

David Howells (2):
  firmware: fold successful fw read early
  firmware: generalize reading file contents as a helper

Luis R. Rodriguez (3):
  firmware: generalize "firmware" as "system data" helpers
  firmware: move completing fw into a helper
  firmware: add an extensible system data helpers

 Documentation/firmware_class/system_data.txt |  71 +++++
 drivers/base/firmware_class.c                | 385 ++++++++++++++++++++++++---
 include/linux/sysdata.h                      | 208 +++++++++++++++
 3 files changed, 627 insertions(+), 37 deletions(-)
 create mode 100644 Documentation/firmware_class/system_data.txt
 create mode 100644 include/linux/sysdata.h

-- 
2.4.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/