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.
Current file loader locations
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.
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()
Desired enhancements
userspace notification of path availability: History on firmware_class has shown 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. The requirements for when a given path is to be ready should then be determined in userspace. 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
Interested developers
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!
Mimi Zohar <zohar@linux.vnet.ibm.com>
"Luis R. Rodriguez" <mcgrof@suse.com>
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>