3263
Comment:
|
3086
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
= WORK IS DONE = | = Common kernel file loader = |
Line 5: | Line 5: |
This work is done. Refer to upstream APIs: | This page documents progress the original goal behind creating common kernel file loader routine on the kernel. For a while it was looked down upon to directly read files from Linux. Then for a while a few kernel mechanisms started creeping up which read files from the filesystem directly from the kernel which did this in a generic from by loading a file into a local kernel buffer. There used to be minor but important checks differences on each, Mimi Zohar looked at each one, took all the best practices from each of them, and generalized a solution. The new APIs available are then: |
Line 11: | Line 11: |
= Common kernel file loader = This page documents progress the goal of a generic kernel file loader routine on the kernel. For a while it was looked down upon to directly read files from Linux. These days there exists a few mechanisms in the kernel that do just this though to load a file into a local buffer. There are minor but important checks differences on each, we should take all the best practices from each of them, generalize them and make all places in the kernel that read a file use it. |
|
Line 19: | Line 15: |
These are the currently known file loader solutions in place on the kernel. There can be more, if you aware of others please list them here. Perhaps a coccinelle script can be used to hunt for them. | These are the currently known file loader solutions in place on the kernel. As you grep the kernel feel free to add more here to help document its use. |
Line 21: | Line 17: |
* firmware_class: fw_read_file() (see [http://kernelnewbies.org/KernelProjects/firmware-class-enhancements this page for further enhancements on firmware_class]) * module: kernel_read() * kexec: copy_file_fd() * IMA: integrity_read_file() * sound: do_mod_firmware_load() |
* firmware_class: Used to be fw_read_file() (see [http://kernelnewbies.org/KernelProjects/firmware-class-enhancements this page for further enhancements on firmware_class]) * module: Used to be kernel_read() * kexec: Used to be copy_file_fd() * IMA: Used to be integrity_read_file() * sound: Used to be do_mod_firmware_load() |
Line 29: | Line 25: |
* userspace notification of path availability: some device drivers (input, wireless) load require loading firmware on probe in order to be able to read any capability information from the device. History on firmware_class has shown though that races can exist on users of its APIs on init/probe due to uses of pivot_root() (as an example), we probably should devise a ''generic'' userspace hint helper that informs the kernel when a path is available. The core kernel file loader could use this to ensure that when it returns 'file not found' it actually means it. Due to things like pivot_root() a system administrator and userspace then can really only know when a given path really is ready for files to be read from it. The requirements for when a given path is to be ready should then be determined in userspace as well. Core file loader users might want to use async file loaders then to wait for such signals. * usermode helpers: the firmware_class module has historically supported a custom "user mode helper" -- it use is being phased out from most kernel users, however, some drivers may still forever require them. A generic solution perhaps might be best. The firmware_class would load things from /lib/firmware/ and similar paths but other solutions in the kernel might use alternative paths. Consideration for usermode helpers for all the above uses cases found should be made |
This lists a few set of enhancement considerations for the core kernel common file loaders. |
Line 32: | Line 27: |
= Interested developers = | == Userspace notification of path availability == |
Line 34: | Line 29: |
We plan on developing this after the holidays (January-February 2016), if you happen to have time to develop a solution before that its all yours! | Some device drivers (input, wireless) load require loading firmware on probe in order to be able to read any capability information from the device. History on firmware_class has shown though that races can exist on users of its APIs on init/probe due to uses of pivot_root() (as an example), we probably should devise a ''generic'' userspace hint helper that informs the kernel when a path is available. The core kernel file loader could use this to ensure that when it returns 'file not found' it actually means it. Due to things like pivot_root() a system administrator and userspace then can really only know when a given path really is ready for files to be read from it. The requirements for when a given path is to be ready should then be determined in userspace as well. Core file loader users might want to use async file loaders then to wait for such signals. |
Line 36: | Line 31: |
* Mimi Zohar <zohar@linux.vnet.ibm.com> * "Luis R. Rodriguez" <mcgrof@suse.com> |
== Usermode helpers == |
Line 39: | Line 33: |
= Volunteered developers to review = We'll volunteer these folks to review, as well as obviously fsdevel folks. * David Howells <dhowells@redhat.com> * David Woodhouse <dwmw2@infradead.org> * Kees Cook <keescook@chromium.org> * Dmitry Torokhov <dmitry.torokhov@gmail.com> |
The firmware_class module has historically supported a custom "user mode helper" fallback mechanism -- we cannot remove the custom usermode helper fallback mechanism from the kernel as some kernel build features always forced it on as such we cannot remove it now. It use can however be compartmentalized. Only 2 drivers explicitly require user of the firmware usermode helper fallback mechanism. A generic solution perhaps might be best though. The firmware_class would load things from /lib/firmware/ and similar paths but other solutions in the kernel might use alternative paths. Consideration for usermode helpers for all the above uses cases found should be made. |
Common kernel file loader
This page documents progress the original goal behind creating common kernel file loader routine on the kernel. For a while it was looked down upon to directly read files from Linux. Then for a while a few kernel mechanisms started creeping up which read files from the filesystem directly from the kernel which did this in a generic from by loading a file into a local kernel buffer. There used to be minor but important checks differences on each, Mimi Zohar looked at each one, took all the best practices from each of them, and generalized a solution. The new APIs available are then:
- kernel_read_file()
- kernel_read_file_from_path()
- kernel_read_file_from_fd()
Current file loader locations
These are the currently known file loader solutions in place on the kernel. As you grep the kernel feel free to add more here to help document its use.
firmware_class: Used to be fw_read_file() (see [http://kernelnewbies.org/KernelProjects/firmware-class-enhancements this page for further enhancements on firmware_class])
- module: Used to be kernel_read()
- kexec: Used to be copy_file_fd()
- IMA: Used to be integrity_read_file()
- sound: Used to be do_mod_firmware_load()
Desired enhancements
This lists a few set of enhancement considerations for the core kernel common file loaders.
Userspace notification of path availability
Some device drivers (input, wireless) load require loading firmware on probe in order to be able to read any capability information from the device. History on firmware_class has shown though that races can exist on users of its APIs on init/probe due to uses of pivot_root() (as an example), we probably should devise a generic userspace hint helper that informs the kernel when a path is available. The core kernel file loader could use this to ensure that when it returns 'file not found' it actually means it. Due to things like pivot_root() a system administrator and userspace then can really only know when a given path really is ready for files to be read from it. The requirements for when a given path is to be ready should then be determined in userspace as well. Core file loader users might want to use async file loaders then to wait for such signals.
Usermode helpers
The firmware_class module has historically supported a custom "user mode helper" fallback mechanism -- we cannot remove the custom usermode helper fallback mechanism from the kernel as some kernel build features always forced it on as such we cannot remove it now. It use can however be compartmentalized. Only 2 drivers explicitly require user of the firmware usermode helper fallback mechanism. A generic solution perhaps might be best though. The firmware_class would load things from /lib/firmware/ and similar paths but other solutions in the kernel might use alternative paths. Consideration for usermode helpers for all the above uses cases found should be made.