Messages in this thread | | | Date | Fri, 18 Jul 2014 10:05:14 -0700 | Subject | Re: [PATCH 4/7] firmware_class: perform new LSM checks | From | Kees Cook <> |
| |
On Thu, Jul 17, 2014 at 8:41 PM, James Morris <jmorris@namei.org> wrote: > On Mon, 14 Jul 2014, Kees Cook wrote: > >> This attaches LSM hooks to the existing firmware loading interfaces: >> filesystem-found firmware and demand-loaded blobs. > >> static int fw_get_filesystem_firmware(struct device *device, >> @@ -640,6 +646,12 @@ static ssize_t firmware_loading_store(struct device *dev, >> break; >> case 0: >> if (test_bit(FW_STATUS_LOADING, &fw_buf->status)) { >> + if (security_kernel_fw_from_file(NULL, fw_buf->data, >> + fw_buf->size)) { >> + fw_load_abort(fw_priv); >> + break; >> + } >> + >> set_bit(FW_STATUS_DONE, &fw_buf->status); >> clear_bit(FW_STATUS_LOADING, &fw_buf->status); >> >> > > Can you explain the loading store, and what the semantics are for an LSM > when a NULL is passed as the file?
I'm not sure what you mean by "loading store"?
When NULL is passed as the file, it means that the firmware was passes a blob, and there is no file backing it:
+ * @kernel_fw_from_file: + * Load firmware from userspace. + * @file contains the file structure pointing to the file containing + * the firmware to load. If the module is being loaded from a blob, + * this argument will be NULL. + * @buf pointer to buffer containing firmware contents. + * @size length of the firmware contents. + * Return 0 if permission is granted.
An LSM that has a policy to require a file to back the firmware would reject such loads.
-Kees
-- Kees Cook Chrome OS Security
| |