linux-kernel - [PATCH v5 0/2] firmware: add driver data API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon,  6 Feb 2017 17:08:52 -0800
From:   "Luis R. Rodriguez" <mcgrof@...nel.org>
To:     gregkh@...uxfoundation.org, ming.lei@...onical.com
Cc:     bp@...en8.de, wagi@...om.org, teg@...m.no, mchehab@....samsung.com,
        zajec5@...il.com, linux-kernel@...r.kernel.org,
        markivx@...eaurora.org, stephen.boyd@...aro.org,
        broonie@...nel.org, zohar@...ux.vnet.ibm.com, tiwai@...e.de,
        johannes@...solutions.net, chunkeey@...glemail.com,
        hauke@...ke-m.de, jwboyer@...oraproject.org,
        dmitry.torokhov@...il.com, dwmw2@...radead.org, jslaby@...e.com,
        torvalds@...ux-foundation.org, luto@...capital.net,
        fengguang.wu@...el.com, rpurdie@...ys.net,
        j.anaszewski@...sung.com, Abhay_Salunke@...l.com,
        Julia.Lawall@...6.fr, Gilles.Muller@...6.fr, nicolas.palix@...g.fr,
        dhowells@...hat.com, bjorn.andersson@...aro.org,
        arend.vanspriel@...adcom.com, kvalo@...eaurora.org,
        "Luis R. Rodriguez" <mcgrof@...nel.org>
Subject: [PATCH v5 0/2] firmware: add driver data API

Greg,

This v5 drops the driver porting examples in light of the fact simple
cases do not yet benefit from use of the newer API. The API is purposely
introduced bare bones so new features are easier to review.

This v5 embraces the proposed "driver data" name, extends documentation
to cover the driver data API stress test driver, and simplifies
documentation a bit more as requested. I've taken the time to also
review all checkpatch annoyances.

On the v4 series Linus clarified he's of the position the driver data
API could be a generic API for a generic "load data from the filesystem
or user" requests and that it should be possible to wrap the new
interface in the old firmware API. There's a few questionable things
part of the old firmware API which upon review I could not stomache in
keeping though as either they are very likely not needed anymore or
require more thought to properly implement. As such the new API only
carries on what is sensible from the old API. The questionable things
from the old API are currently not carried forward are:

  o The usermode helper lock: is currently used on the older firmware API
    even if the kernel UMH is not used. The UMH lock was added to help
    avoid a suspend and resume face issue, which the firmware cache fixed.

  o The fallback mechanism: the fallback mechanism is rather complex and
    supports a custom fallback mechanism. As recent patches reveal this
    was not well tested for a while. We also know systemd udev has long
    had the fallback mechanism ripped out, and some distributions simply
    ignore these requestions all together (Debian). A few new users of
    the fallback mechanism have come to light however and upon review it
    would seem we can address support for these users using the default
    fallback mechanism with kobject uevents even if a custom path is
    required, and a new userspace solution which replaces the old
    systemd udev fallback helper. Long term then the custom fallback
    mechanism proves pointless to extend.

Lastly, we now have the new common kernel_read_file_from_fd() and
kernel_read_file_from_path() with respective LSM hooks and identifiers
for LSMs for reading files from the kernel for:

  o READING_UNKNOWN
  o READING_FIRMWARE
  o READING_FIRMWARE_PREALLOC_BUFFER
  o READING_MODULE
  o READING_KEXEC_IMAGE
  o READING_KEXEC_INITRAMFS
  o READING_POLICY

If we want to support a fallback mechanism and/or custom paths on the
driver data API to generalize it more we'd need to revise how we'd want
to expand on context to feed LSMs. For now though the driver data API
only supports and uses kernel_read_file_from_path() and uses the
READING_FIRMWARE id only as this is where the code grew from.

Luis R. Rodriguez (2):
  firmware: add extensible driver data API
  test: add new driver_data load tester

 Documentation/driver-api/firmware/driver_data.rst  |  109 ++
 Documentation/driver-api/firmware/index.rst        |    1 +
 Documentation/driver-api/firmware/introduction.rst |   16 +
 MAINTAINERS                                        |    4 +-
 drivers/base/firmware_class.c                      |  333 +++++++
 include/linux/driver_data.h                        |  253 +++++
 lib/Kconfig.debug                                  |   12 +
 lib/Makefile                                       |    1 +
 lib/test_driver_data.c                             | 1039 ++++++++++++++++++++
 tools/testing/selftests/firmware/Makefile          |    2 +-
 tools/testing/selftests/firmware/config            |    1 +
 tools/testing/selftests/firmware/driver_data.sh    |  826 ++++++++++++++++
 12 files changed, 2595 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/driver-api/firmware/driver_data.rst
 create mode 100644 include/linux/driver_data.h
 create mode 100644 lib/test_driver_data.c
 create mode 100755 tools/testing/selftests/firmware/driver_data.sh

-- 
2.11.0