A new feature that appears ready for introduction in the upcoming Linux 6.20~7.0 kernel cycle is revocable resource management.
Google engineer Tzung-Bi Shih began working on this code to fix a possible use-after-free situation within the ChromeOS EC platform driver code. This Revocable Resource Management has since spun out into its own standalone infrastructure code and it’s that is what is on the table for the upcoming Linux 6.20~7.0 kernel cycle.
Queued up this past week into the driver-core code’s "driver-core-next" Git branch is the introduction of Revocable Resource Management, which is explained by Tzung-Bi Shih as:
Some resources can be removed asynchronously, for example, resources provide…
A new feature that appears ready for introduction in the upcoming Linux 6.20~7.0 kernel cycle is revocable resource management.
Google engineer Tzung-Bi Shih began working on this code to fix a possible use-after-free situation within the ChromeOS EC platform driver code. This Revocable Resource Management has since spun out into its own standalone infrastructure code and it’s that is what is on the table for the upcoming Linux 6.20~7.0 kernel cycle.
Queued up this past week into the driver-core code’s "driver-core-next" Git branch is the introduction of Revocable Resource Management, which is explained by Tzung-Bi Shih as:
Some resources can be removed asynchronously, for example, resources provided by a hot-pluggable device like USB. When holding a reference to such a resource, it’s possible for the resource to be removed and its memory freed, leading to use-after-free errors on subsequent access.
The "revocable" mechanism addresses this by establishing a weak reference to a resource that might be freed at any time. It allows a resource consumer to safely attempt to access the resource, guaranteeing that the access is valid for the duration of its use, or it fails safely if the resource has already been revoked.
The implementation uses a provider/consumer model built on Sleepable RCU (SRCU) to guarantee safe memory access:
A resource provider, such as a driver for a hot-pluggable device, allocates a struct revocable_provider and initializes it with a pointer to the resource.
A resource consumer that wants to access the resource allocates a struct revocable which acts as a handle containing a reference to the provider.
To access the resource, the consumer uses revocable_try_access(). This function enters an SRCU read-side critical section and returns the pointer to the resource. If the provider has already freed the resource, it returns NULL. After use, the consumer calls revocable_withdraw_access() to exit the SRCU critical section. The REVOCABLE_TRY_ACCESS_WITH() and REVOCABLE_TRY_ACCESS_SCOPED() are convenient helpers for doing that.
When the provider needs to remove the resource, it calls revocable_provider_revoke(). This function sets the internal resource pointer to NULL and then calls synchronize_srcu() to wait for all current readers to finish before the resource can be completely torn down.
This Revocable Resource Management is based on ideas raised during this LPC 2023 presentation.
With the infrastructure now in driver-core-next it should be found in the next Linux kernel merge window barring any last minute issues. Following that more Linux kernel driver code will be able to begin making use of this revocable code in future patches.