Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030738AbaGRRFT (ORCPT ); Fri, 18 Jul 2014 13:05:19 -0400 Received: from mail-oa0-f54.google.com ([209.85.219.54]:40423 "EHLO mail-oa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030567AbaGRRFP (ORCPT ); Fri, 18 Jul 2014 13:05:15 -0400 MIME-Version: 1.0 In-Reply-To: References: <1405373897-31671-1-git-send-email-keescook@chromium.org> <1405373897-31671-5-git-send-email-keescook@chromium.org> Date: Fri, 18 Jul 2014 10:05:14 -0700 X-Google-Sender-Auth: Cga2G1hGDCQAGJQ5kUiV86UXXOc Message-ID: Subject: Re: [PATCH 4/7] firmware_class: perform new LSM checks From: Kees Cook To: James Morris Cc: LKML , Ming Lei , "Luis R. Rodriguez" , Greg Kroah-Hartman , James Morris , David Howells , "linux-doc@vger.kernel.org" , linux-security-module , linux-firmware@kernel.org, linux-wireless Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 17, 2014 at 8:41 PM, James Morris 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/