On Mon, Jul 14, 2014 at 02:38:13PM -0700, Kees Cook wrote: > +int security_kernel_fw_from_file(struct file *file, char *buf, size_t size) > +{ > + return security_ops->kernel_fw_from_file(file, buf, size); > +} > +EXPORT_SYMBOL_GPL(security_kernel_fw_from_file); I have a use case in mind already (CRDA) whereby a non-driver but a core part of the kernel would like to use the request_firmware_direct() API and leave it optional to that part of the kernel if or not a digital signature check is required since this is already an optional feature. Since LSM would be used for the digital signatures it it'd be good if we allowed drivers and the kernel to specify whether or not a the LSM signature hook does indeed need to be used. Additionally there may be different signature requirements on the file, one might be willing to *require* a digital signature check even if say dm-verity was used, one use case here is wanting the to require as part of the specification a one to one mapping of file --> signature. That may be a bit paranoid... but its certainly a possibility. This could be addressed by allowing a user to express whether one security mechanism is sufficient for an expected one, or if one is definitely required. One example here could be the ability for a driver / kernel to express that dm-verity would not suffice for a request_firmware_direct() call. I'm not saying that I *know* this use case exists, am just saying I can expect it and do consider it subjective to assume we'd agree on possible security intersections. I see this also adds a hook for fw itself, meanwhile we already had one for modules. The request_firmware() API is already used on other areas of the kernel for non-firmware files, it can be used to load optional CPU microcode upgrade, EEPROM optional override files, and in the wireless case I'd like to see if we could replace CRDA by using the same APIs / mechanisms as well to avoid having to deal with complexities on parsers with CFG80211_INTERNAL_REGDB. Besides nomenclature fuzz as usage of request_firmware() API grows it occurs to me that perhaps these hooks could be generalized at the kobject granularity level. That should make it easier to scale and consider these LSM hooks for any type of other object in the kernel in the future. kobjects may be overkill though, unless we could enable the option to have have these hooks only optional for certain type of kobjects. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html