Differences between revisions 14 and 15
|Deletions are marked like this.||Additions are marked like this.|
|Line 82:||Line 82:|
= Custom module reference counting =
The old firmware APIs refcounted the firmware_class module for synchronous
requests, meanwhile asynchronous requests refcounted the caller's module.
The driver data request API currently mimics this behaviour, for synchronous
requests the firmware_class module is refcounted through the use of
dfl_sync_reqs. In the future we may enable the ability to also refcount the
caller's module as well. Likewise in the future we may enable asynchronous
calls to refcount the firmware_class module.
Linux firmware_class enhancements
- Linux firmware_class enhancements
- Firmware usermode helper fallback enhancements
- Extensible firmware API
- Firmware signing
- Firmware calls on init and probe
- Core file loader
- Custom module reference counting
- Desired features
Firmware usermode helper fallback enhancements
The firmware API makes use of a custom usermode helper fallback mechanism should direct filesystem loading fail. Its a custom usermode helper mechanism since it only uses the core kernel kobject uevent (which is one real user of the core kernel usermode helper) as an optional feature, but also always relies on the core usermode helper lock. There are a slew of issue with this. Daniel Wagner has nose dived into this code to help compartamentalize it as best as possible first without creating any side effects, with long term plans to replace custom hacks with generic functionality in the kernel.
Since a lot of the usermode helper functionality is tied to the core kernel usermode helper or implicates it or its users if we make any changes to it the firmware usermode helper functionality and enhancement considerations are currently being documented on the usermode helper enhancement page. An overview of the key enhancement ideas though:
The firmware cache which was later added helps avoid the race concerns which we originally had when using the firmware API on suspend/resume, it only works for firmware API users which do not explicitly request use of the firmware usermode helper fallback mechanism
There exists a kernel functionality to help address races with block devices -- freeze_super() can be used to queue superblock filesystem operations. For inspiration we can review and consider the patch being worked on by Jiri Kosina which freezes all filesystems during suspend. This would resolve the suspend/resume race concerns for the lock, it however does not solve the races on init.
Extensible firmware API
At the 2015 kernel summit it was agreed that the firmware signing facility would be generalized, callers of the firmware API already exist outside of "firmware" use, so re-branding is over due to annotate for this. Greg has noted we cannot get rid of the usermode helper, but even Linus has called for deprecating the usermode helper, a compromise is to phase the usermode helper out of most common kernel users by having the usermode helper exist only for old users. A clean series of APIs for "firmware loading" with a rebranded set of APIs will be added to enable to skip the usermode helper, make emphasis that the loader is not just for firmware, but for other things, and later get support for "firmware signing". The usermode helper code then would be compartmentalized and slowly faded.
Suppose that there's some trusted keypair. The SHA256 hash of the public key is cdbcba8ee7cd604391d409872a0655d9170fcf93fd3cfca4b648559881ce4a70. There's a firmware file called "firmware.bin". The firmware file has sha256sum 81357924283b5a6a803e8bcc8fce12b0f11bf575abff9356d1a32f987b0f0022.
Then sign that using whatever signature algorithm. The signature is the public key hash followed by the raw signature. RSA PKCS #1 2.0 signatures would be fine. PKCS #1 1.5 would be okay, too, but it's a little sad. ECDSA over P-256 would probably be fine.
Firmware calls on init and probe
Asynchronous probe was added to help with delayed boots caused by use of fw API calls, and by the generic 30 second systemd timeout. There is still an issue present when fw APIs are used on init or probe: the kernel cannot be sure that /lib/firmware is ready. In particular when switching initramfs with pivot_root(), for example. In such cases even if you use asynchronous probe on probe you might end up with a system that finds no firmware yet on /lib/firmware as the filesystem for it might not be ready.
A coccinelle rule is being worked on which maps out the users of the firmware API on init and probe, interprocedurally (calls that calls fw API too), the list is pretty big, the patch / details wil be posted soon for review.
A userspace hint to the kernel when /lib/firmware is ready is needed. Note that this hint might be something we likely can make use of for other subsystems which may need file loading on other paths on the filesystem, depending on where the subsystem is loading files from the kernel.
Core file loader
Except for some new enhancement considerations this work is now done ! for details refer to: common file loader page
Summary: there used to be 5 different kernel file loaders, all doing the same exact thing: reading files directly from the filesystem to the kernel. An outstanding issue with it though are races against reading files from the filesystem upon suspend/resume and on init.
Custom module reference counting
The old firmware APIs refcounted the firmware_class module for synchronous requests, meanwhile asynchronous requests refcounted the caller's module. The driver data request API currently mimics this behaviour, for synchronous requests the firmware_class module is refcounted through the use of dfl_sync_reqs. In the future we may enable the ability to also refcount the caller's module as well. Likewise in the future we may enable asynchronous calls to refcount the firmware_class module.