Received: by 10.192.165.148 with SMTP id m20csp5284872imm; Tue, 1 May 2018 12:13:25 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrz7Aq/F/1u8TAYSjjj4m0SaJalryPTN7cgxeru+8JF+2g4MxmqboLGxyeyIYaqCzdyVYZP X-Received: by 2002:a63:7003:: with SMTP id l3-v6mr50143pgc.14.1525202005499; Tue, 01 May 2018 12:13:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1525202005; cv=none; d=google.com; s=arc-20160816; b=fflMxr1rbhA6McDjaBVpRurFSoqmUD5W3mR8Z49PXGKYn9izim14huwweWwXaB5zmH mWcC2Lva0aD1zyEio8Dsn3K2rdlcQQd41STjWKQVBBont2v7uLXMneg9MrTxjYyJCEJR TSsnbZniW+SGcFwZXJ+Vr49Ch3fP8VlxVRV4PiAW9PycR+/diTqTQx3jdJZYxPOT4V/t 0kf2RKcOMMV9mh+wQ2RQNkPoF7yzGvum9Q9t0YzpF4Nwm2BFbcnDGIB4YNE4QZydDt+T TtM7uY7DUmYZMI+EWVjTvOND4Qli7R02PrI+SO9DaEFXtlFTvbXmM+330ZUQIfol5J0s wb8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=aR8jMkoU4yFdtVJsJYVnJLTxYwEf/7bSa+vrsPHb2vc=; b=LaaWs0T+YcEvpms81/DO6a68b/iAs59UYHu4hBeLM43G4fUWVPNZj17XhhTuTAnsfK 8E4csuwZUoB9nI9LJDRw0ajdYV02t95Zhr5w1yC6zDnjPDuTZieuB9RTfdeGFbkeBe6J aYHxQN96ycisNihV1S2Fzr71hZlUqZTc3daSG/j3YkdrNCkUB3H36ZzynbDTkwQzHKeP 0+Se9LfsIWsTmWdtITjmR5+s5rYHUsbWSFwdPspdmpTfIEBn7pf5Bog7vGf+OLDvJl9l 8tii0I3i4R1amb4iLsGE7XlENQar+KwAFg6K80rDb20FZxJLA4zU2Fm46spq2tgb7i/n piXQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y3si10376417pfa.181.2018.05.01.12.13.11; Tue, 01 May 2018 12:13:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756591AbeEATLa (ORCPT + 99 others); Tue, 1 May 2018 15:11:30 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:38068 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756157AbeEATL2 (ORCPT ); Tue, 1 May 2018 15:11:28 -0400 Received: by mail-wm0-f68.google.com with SMTP id i3so20376813wmf.3 for ; Tue, 01 May 2018 12:11:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=aR8jMkoU4yFdtVJsJYVnJLTxYwEf/7bSa+vrsPHb2vc=; b=JRwJAakSMrYEtuKgkwdEr4zEIcNINbE2D0HDWVjkr+e66w26O5hzVEiouXAjjeNZ7O b6tp3c5feUKYXFKvlgTeHhPO0Ki/VOPb5PRNDnuL2BxZOhrZpMsk/M0oYExaauQpQacV vqj2R1xzI1yP8uXQ8yAYJu+IZ45cay3OvZPw8PA5CBFcjC0CcS1KOQKYvVTIOs/9ujgw sR6bmF3jVcmTdB0E0gdq1PWtOdPyjj2QmZ8PMpI9WYPDjzyXUFrZAXLBz0WjHCu9UEcc THKWhl9XK/8q32P2mizBR2021GTmhQkl+0XEV3pvzeIEBjuxhLLMV+jzb+ItsfoCSVKU qTvA== X-Gm-Message-State: ALQs6tDB3BWSkrBgxcYkQJcKoZaWuJo0bfdG3ucc0cDujRl1VZmCXzvk pNMh5vDcmdp35AIiUsi9f7vJEw== X-Received: by 2002:a50:97a3:: with SMTP id e32-v6mr22449857edb.58.1525201887166; Tue, 01 May 2018 12:11:27 -0700 (PDT) Received: from shalem.localdomain (546A5441.cm-12-3b.dynamic.ziggo.nl. [84.106.84.65]) by smtp.gmail.com with ESMTPSA id j89-v6sm5984409edd.37.2018.05.01.12.11.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 May 2018 12:11:26 -0700 (PDT) Subject: Re: [PATCH v5 2/5] efi: Add embedded peripheral firmware support To: Mimi Zohar , Ard Biesheuvel , "Luis R . Rodriguez" , Greg Kroah-Hartman , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" Cc: Peter Jones , Dave Olsthoorn , Will Deacon , Andy Lutomirski , Matt Fleming , David Howells , Josh Triplett , dmitry.torokhov@gmail.com, mfuzzey@parkeon.com, Kalle Valo , Arend Van Spriel , Linus Torvalds , nbroeking@me.com, bjorn.andersson@linaro.org, Torsten Duwe , Kees Cook , x86@kernel.org, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-security-module References: <20180429093558.5411-1-hdegoede@redhat.com> <20180429093558.5411-3-hdegoede@redhat.com> <1525185374.5669.49.camel@linux.vnet.ibm.com> From: Hans de Goede Message-ID: Date: Tue, 1 May 2018 21:11:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <1525185374.5669.49.camel@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 01-05-18 16:36, Mimi Zohar wrote: > [Cc'ing linux-security] > > On Sun, 2018-04-29 at 11:35 +0200, Hans de Goede wrote: > [...] >> diff --git a/drivers/base/firmware_loader/fallback_efi.c b/drivers/base/firmware_loader/fallback_efi.c >> new file mode 100644 >> index 000000000000..82ba82f48a79 >> --- /dev/null >> +++ b/drivers/base/firmware_loader/fallback_efi.c >> @@ -0,0 +1,51 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> + >> +#include >> +#include >> +#include >> +#include >> + >> +#include "fallback.h" >> +#include "firmware.h" >> + >> +int fw_get_efi_embedded_fw(struct device *dev, struct fw_priv *fw_priv, >> + enum fw_opt *opt_flags, int ret) >> +{ >> + enum kernel_read_file_id id = READING_FIRMWARE; > > Please define a new kernel_read_file_id for this (eg. > READING_FIRMWARE_EFI_EMBEDDED). Are you sure, I wonder how useful it is to add a new kernel_read_file_id every time a new way to get firmware comes up? I especially wonder about the sense in adding a new id given that the quite old FIRMWARE_PREALLOC_BUFFER is still not supported / checked properly by the security code. Anyways I can add a new id if you want me to, what about when fw_get_efi_embedded_fw is reading into a driver allocated buffer, do you want a separate EADING_FIRMWARE_EFI_EMBEDDED_PREALLOC_BUFFER for that ? > >> + size_t size, max = INT_MAX; >> + int rc; >> + >> + if (!dev) >> + return ret; >> + >> + if (!device_property_read_bool(dev, "efi-embedded-firmware")) >> + return ret; > > Instead of calling security_kernel_post_read_file(), either in > device_property_read_bool() or here call security_kernel_read_file(). > > The pre read call is for deciding whether to allow this call > independent of the firmware being loaded, whereas the post security > call is currently being used by IMA-appraisal for verifying a > signature.  There might be other LSMs using the post hook as well.  As > there is no kernel signature associated with this firmware, use the > security pre read_file hook. Only the pre hook? I believe the post-hook should still be called too, right? So that we've hashes of all loaded firmwares in the IMA core. Regards, Hans > > thanks, > > Mimi > >> + >> + *opt_flags |= FW_OPT_NO_WARN | FW_OPT_NOCACHE | FW_OPT_NOFALLBACK; >> + >> + /* Already populated data member means we're loading into a buffer */ >> + if (fw_priv->data) { >> + id = READING_FIRMWARE_PREALLOC_BUFFER; >> + max = fw_priv->allocated_size; >> + } >> + >> + rc = efi_get_embedded_fw(fw_priv->fw_name, &fw_priv->data, &size, max); >> + if (rc) { >> + dev_warn(dev, "Firmware %s not in EFI\n", fw_priv->fw_name); >> + return ret; >> + } >> + >> + rc = security_kernel_post_read_file(NULL, fw_priv->data, size, id); >> + if (rc) { >> + if (id != READING_FIRMWARE_PREALLOC_BUFFER) { >> + vfree(fw_priv->data); >> + fw_priv->data = NULL; >> + } >> + return rc; >> + } >> + >> + dev_dbg(dev, "using efi-embedded fw %s\n", fw_priv->fw_name); >> + fw_priv->size = size; >> + fw_state_done(fw_priv); >> + return 0; >> +} >