Message ID | 20230224201918.411492-1-amadeuszx.slawinski@linux.intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp874300wrd; Fri, 24 Feb 2023 04:23:12 -0800 (PST) X-Google-Smtp-Source: AK7set8CaGD5g2EsuRxpvKwR18GG/7d1P1UEahahZ5TAwlBGGFQbHlm/9JLjaIGAinBnACjJFfkc X-Received: by 2002:a17:907:c29:b0:8b1:76ca:f228 with SMTP id ga41-20020a1709070c2900b008b176caf228mr37111168ejc.39.1677241391498; Fri, 24 Feb 2023 04:23:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1677241391; cv=none; d=google.com; s=arc-20160816; b=EiDvDgcgyJdmKXB1gfAP1FaNiG8SKiZFRIS7CaPrd5QTskeTiLHh4RPTcJrHxJ5UUH GeeWL7qObKoelBRClV9VwhCx4MCM6y3yB0P9jlQDJpYaxSpyUD33aVH7glq/D3kVgSOc rurkV2ngZmoPOLTPr548WfZKkb2iyC+hRa7d7r2d8V4wOFnsB2MJUl/vf1htpTgQ7kaw Vr6z8cUF1DXy4G1tk8igRK0goDRcK7GxSYYDaalBXe07UPInnFwxX5GpfzF5hheKMTpE YCoMTqDc2PMO/Mqs/oA0IXHv7cQh0CzTQ2ovjYCc0XB93haMeAxIGZ25R0leC9n9rzF2 j3jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=VL6K6j54eJMkpfXuhYVyv8JGnQ/pO77PbiX+TfPrQtU=; b=LrIaEfyhLDRm3pY4lvTIfFm0VZwii05q0YDCkx8b4kjbixF52MtecuKN0YY+sf3t/b 7OhC23Asm32FlmdlrI0AEtn7C/AvgyGpg67IU5BKpomDymnU94vlwrUZcAYg+XhoJ4+i 087a1upAAtszP2LRg9uzjfHaqIeiOo9wQHcf+MPUqr9KIiXY3bQe64lBUaRlmiM+XMb1 bH0GeMxQg8nvpSGbAEg2N+loM/F9tHGxiyC1s+jQ01SnO4BJOShY1noy/aQp6hzCv9W9 RjouA2ImewXGLHQ4S8SFWrMH3WU2zrE43cUC76rDpUmpqAMYELkXlONzjWB7iPiAkWT4 bU5g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=c6wrX2yk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id r8-20020a170906958800b008d086af4a5esi15279395ejx.155.2023.02.24.04.22.47; Fri, 24 Feb 2023 04:23:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=c6wrX2yk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229939AbjBXMST (ORCPT <rfc822;jeff.pang.chn@gmail.com> + 99 others); Fri, 24 Feb 2023 07:18:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47696 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229522AbjBXMSS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 24 Feb 2023 07:18:18 -0500 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3B9055D45C for <linux-kernel@vger.kernel.org>; Fri, 24 Feb 2023 04:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1677241097; x=1708777097; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=qcqcS60w/GcK63CF6bpBLMPCivlaNmvCj1bpX8DfmdY=; b=c6wrX2ykj6Kc7mOTlAbJ7WKIxMW24nXIfb9K+ocs23OlV3PInFEx2Rd8 w/saxJ5pkWOayypRrcbZq4gDiZHYKlfS1DQ5qUoj589VlBjSM1EsVOnL6 3HAS9ytIL8FuMpmOOPUN+CxAVXlXxv4ftKLgaUVfd+oFvO+h0wloHfXhG KhakumzY28K6owFf0ZIcoHZL/4b66O/R7cNQYJgyLY0lEx01f2LerXjPd RbEYYCfuEG2LXkTXDJ5E0viwYy7yMeffU2rqomrnZaxLQwiH8dvco8V0+ qK4YACixexTrHLDyNLO4S8u/xjW6dfMsVKzJVcXtsDPo+BKFBkIGx2VBe Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10630"; a="332148342" X-IronPort-AV: E=Sophos;i="5.97,324,1669104000"; d="scan'208";a="332148342" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Feb 2023 04:18:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10630"; a="761766565" X-IronPort-AV: E=Sophos;i="5.97,324,1669104000"; d="scan'208";a="761766565" Received: from dev2.igk.intel.com ([10.237.148.94]) by FMSMGA003.fm.intel.com with ESMTP; 24 Feb 2023 04:18:15 -0800 From: =?utf-8?q?Amadeusz_S=C5=82awi=C5=84ski?= <amadeuszx.slawinski@linux.intel.com> To: Russ Weight <russell.h.weight@intel.com>, Luis Chamberlain <mcgrof@kernel.org>, linux-kernel@vger.kernel.org Cc: Cezary Rojewski <cezary.rojewski@intel.com>, "Rafael J . Wysocki" <rafael.j.wysocki@intel.com>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, =?utf-8?q?Amadeusz_S=C5=82?= =?utf-8?q?awi=C5=84ski?= <amadeuszx.slawinski@linux.intel.com> Subject: [PATCH] firmware_loader: Add debug message with checksum for FW file Date: Fri, 24 Feb 2023 21:19:18 +0100 Message-Id: <20230224201918.411492-1-amadeuszx.slawinski@linux.intel.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_06_12, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1758715069432140750?= X-GMAIL-MSGID: =?utf-8?q?1758715069432140750?= |
Series |
firmware_loader: Add debug message with checksum for FW file
|
|
Commit Message
Amadeusz Sławiński
Feb. 24, 2023, 8:19 p.m. UTC
Enable dynamic-debug logging of firmware filenames and SHA256 checksums to clearly identify the firmware files that are loaded by the system. Example output: [ 34.944619] firmware_class:_request_firmware: i915 0000:00:02.0: Loaded FW: i915/kbl_dmc_ver1_04.bin, sha256: 2cde41c3e5ad181423bcc3e98ff9c49f743c88f18646af4d0b3c3a9664b831a1 [ 48.155884] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/cnl/dsp_basefw.bin, sha256: 43f6ac1b066e9bd0423d914960fbbdccb391af27d2b1da1085eee3ea8df0f357 [ 49.579540] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/rt274-tplg.bin, sha256: 4b3580da96dc3d2c443ba20c6728d8b665fceb3ed57223c3a57582bbad8e2413 [ 49.798196] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/hda-8086280c-tplg.bin, sha256: 5653172579b2be1b51fd69f5cf46e2bac8d63f2a1327924311c13b2f1fe6e601 [ 49.859627] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/dmic-tplg.bin, sha256: 00fb7fbdb74683333400d7e46925dae60db448b88638efcca0b30215db9df63f Reviewed-by: Russ Weight <russell.h.weight@intel.com> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> --- drivers/base/firmware_loader/main.c | 45 ++++++++++++++++++++++++++++- 1 file changed, 44 insertions(+), 1 deletion(-)
Comments
On Fri, Feb 24, 2023 at 09:19:18PM +0100, Amadeusz Sławiński wrote: > Enable dynamic-debug logging of firmware filenames and SHA256 checksums > to clearly identify the firmware files that are loaded by the system. > > Example output: > [ 34.944619] firmware_class:_request_firmware: i915 0000:00:02.0: Loaded FW: i915/kbl_dmc_ver1_04.bin, sha256: 2cde41c3e5ad181423bcc3e98ff9c49f743c88f18646af4d0b3c3a9664b831a1 > [ 48.155884] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/cnl/dsp_basefw.bin, sha256: 43f6ac1b066e9bd0423d914960fbbdccb391af27d2b1da1085eee3ea8df0f357 > [ 49.579540] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/rt274-tplg.bin, sha256: 4b3580da96dc3d2c443ba20c6728d8b665fceb3ed57223c3a57582bbad8e2413 > [ 49.798196] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/hda-8086280c-tplg.bin, sha256: 5653172579b2be1b51fd69f5cf46e2bac8d63f2a1327924311c13b2f1fe6e601 > [ 49.859627] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/dmic-tplg.bin, sha256: 00fb7fbdb74683333400d7e46925dae60db448b88638efcca0b30215db9df63f > > Reviewed-by: Russ Weight <russell.h.weight@intel.com> > Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> > Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> > --- > drivers/base/firmware_loader/main.c | 45 ++++++++++++++++++++++++++++- > 1 file changed, 44 insertions(+), 1 deletion(-) > > diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c > index 017c4cdb219e..a6e1fb10763d 100644 > --- a/drivers/base/firmware_loader/main.c > +++ b/drivers/base/firmware_loader/main.c > @@ -791,6 +791,47 @@ static void fw_abort_batch_reqs(struct firmware *fw) > mutex_unlock(&fw_lock); > } > > +#if defined(DEBUG) || defined(CONFIG_DYNAMIC_DEBUG) > +#include <crypto/hash.h> > +#include <crypto/sha2.h> > +#define SHA256_STRING_SIZE (SHA256_DIGEST_SIZE * 2) > +static void fw_log_firmware_info(const struct firmware *fw, const char *name, struct device *device) > +{ > + char outbuf[SHA256_STRING_SIZE + 1]; > + u8 sha256buf[SHA256_DIGEST_SIZE]; Nit, these are big, are you _SURE_ you can put them on the stack ok? Why not dynamically allocate them? > + struct shash_desc *shash; > + struct crypto_shash *alg; > + > + alg = crypto_alloc_shash("sha256", 0, 0); Do we need to select this in the .config as well? > + if (!alg) > + return; > + > + shash = kmalloc(sizeof(*shash) + crypto_shash_descsize(alg), GFP_KERNEL); kmalloc_array()? > + if (!shash) > + goto out_alg; > + > + shash->tfm = alg; > + > + if (crypto_shash_digest(shash, fw->data, fw->size, sha256buf) < 0) > + goto out_shash; > + > + for (int i = 0; i < SHA256_DIGEST_SIZE; i++) > + sprintf(&outbuf[i * 2], "%02x", sha256buf[i]); > + outbuf[SHA256_STRING_SIZE] = 0; > + dev_dbg(device, "Loaded FW: %s, sha256: %s\n", name, outbuf); > + > +out_shash: > + kfree(shash); > +out_alg: > + crypto_free_shash(alg); Otherwise, just tiny comments, overall this looks nice, thanks for doing this. greg k-h
On 2/24/2023 1:46 PM, Greg Kroah-Hartman wrote: > On Fri, Feb 24, 2023 at 09:19:18PM +0100, Amadeusz Sławiński wrote: >> Enable dynamic-debug logging of firmware filenames and SHA256 checksums >> to clearly identify the firmware files that are loaded by the system. >> >> Example output: >> [ 34.944619] firmware_class:_request_firmware: i915 0000:00:02.0: Loaded FW: i915/kbl_dmc_ver1_04.bin, sha256: 2cde41c3e5ad181423bcc3e98ff9c49f743c88f18646af4d0b3c3a9664b831a1 >> [ 48.155884] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/cnl/dsp_basefw.bin, sha256: 43f6ac1b066e9bd0423d914960fbbdccb391af27d2b1da1085eee3ea8df0f357 >> [ 49.579540] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/rt274-tplg.bin, sha256: 4b3580da96dc3d2c443ba20c6728d8b665fceb3ed57223c3a57582bbad8e2413 >> [ 49.798196] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/hda-8086280c-tplg.bin, sha256: 5653172579b2be1b51fd69f5cf46e2bac8d63f2a1327924311c13b2f1fe6e601 >> [ 49.859627] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/dmic-tplg.bin, sha256: 00fb7fbdb74683333400d7e46925dae60db448b88638efcca0b30215db9df63f >> >> Reviewed-by: Russ Weight <russell.h.weight@intel.com> >> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> >> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> >> --- >> drivers/base/firmware_loader/main.c | 45 ++++++++++++++++++++++++++++- >> 1 file changed, 44 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c >> index 017c4cdb219e..a6e1fb10763d 100644 >> --- a/drivers/base/firmware_loader/main.c >> +++ b/drivers/base/firmware_loader/main.c >> @@ -791,6 +791,47 @@ static void fw_abort_batch_reqs(struct firmware *fw) >> mutex_unlock(&fw_lock); >> } >> >> +#if defined(DEBUG) || defined(CONFIG_DYNAMIC_DEBUG) >> +#include <crypto/hash.h> >> +#include <crypto/sha2.h> >> +#define SHA256_STRING_SIZE (SHA256_DIGEST_SIZE * 2) >> +static void fw_log_firmware_info(const struct firmware *fw, const char *name, struct device *device) >> +{ >> + char outbuf[SHA256_STRING_SIZE + 1]; >> + u8 sha256buf[SHA256_DIGEST_SIZE]; > > Nit, these are big, are you _SURE_ you can put them on the stack ok? > Why not dynamically allocate them? > Well, those arrays are not that big? First one is 65 bytes and other one 32. Although now that I looked again at the header, there is SHA256_BLOCK_SIZE define for string size, so I will change SHA256_STRING_SIZE to that instead. >> + struct shash_desc *shash; >> + struct crypto_shash *alg; >> + >> + alg = crypto_alloc_shash("sha256", 0, 0); > > Do we need to select this in the .config as well? > Most likely. >> + if (!alg) >> + return; >> + >> + shash = kmalloc(sizeof(*shash) + crypto_shash_descsize(alg), GFP_KERNEL); > > kmalloc_array()? > Yes. >> + if (!shash) >> + goto out_alg; >> + >> + shash->tfm = alg; >> + >> + if (crypto_shash_digest(shash, fw->data, fw->size, sha256buf) < 0) >> + goto out_shash; >> + >> + for (int i = 0; i < SHA256_DIGEST_SIZE; i++) >> + sprintf(&outbuf[i * 2], "%02x", sha256buf[i]); >> + outbuf[SHA256_STRING_SIZE] = 0; >> + dev_dbg(device, "Loaded FW: %s, sha256: %s\n", name, outbuf); >> + >> +out_shash: >> + kfree(shash); >> +out_alg: >> + crypto_free_shash(alg); > > Otherwise, just tiny comments, overall this looks nice, thanks for doing > this. > > greg k-h
On Fri, Feb 24, 2023 at 01:54:33PM +0100, Amadeusz Sławiński wrote: > On 2/24/2023 1:46 PM, Greg Kroah-Hartman wrote: > > On Fri, Feb 24, 2023 at 09:19:18PM +0100, Amadeusz Sławiński wrote: > > > Enable dynamic-debug logging of firmware filenames and SHA256 checksums > > > to clearly identify the firmware files that are loaded by the system. > > > > > > Example output: > > > [ 34.944619] firmware_class:_request_firmware: i915 0000:00:02.0: Loaded FW: i915/kbl_dmc_ver1_04.bin, sha256: 2cde41c3e5ad181423bcc3e98ff9c49f743c88f18646af4d0b3c3a9664b831a1 > > > [ 48.155884] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/cnl/dsp_basefw.bin, sha256: 43f6ac1b066e9bd0423d914960fbbdccb391af27d2b1da1085eee3ea8df0f357 > > > [ 49.579540] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/rt274-tplg.bin, sha256: 4b3580da96dc3d2c443ba20c6728d8b665fceb3ed57223c3a57582bbad8e2413 > > > [ 49.798196] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/hda-8086280c-tplg.bin, sha256: 5653172579b2be1b51fd69f5cf46e2bac8d63f2a1327924311c13b2f1fe6e601 > > > [ 49.859627] firmware_class:_request_firmware: snd_soc_avs 0000:00:1f.3: Loaded FW: intel/avs/dmic-tplg.bin, sha256: 00fb7fbdb74683333400d7e46925dae60db448b88638efcca0b30215db9df63f > > > > > > Reviewed-by: Russ Weight <russell.h.weight@intel.com> > > > Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> > > > Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> > > > --- > > > drivers/base/firmware_loader/main.c | 45 ++++++++++++++++++++++++++++- > > > 1 file changed, 44 insertions(+), 1 deletion(-) > > > > > > diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c > > > index 017c4cdb219e..a6e1fb10763d 100644 > > > --- a/drivers/base/firmware_loader/main.c > > > +++ b/drivers/base/firmware_loader/main.c > > > @@ -791,6 +791,47 @@ static void fw_abort_batch_reqs(struct firmware *fw) > > > mutex_unlock(&fw_lock); > > > } > > > +#if defined(DEBUG) || defined(CONFIG_DYNAMIC_DEBUG) > > > +#include <crypto/hash.h> > > > +#include <crypto/sha2.h> > > > +#define SHA256_STRING_SIZE (SHA256_DIGEST_SIZE * 2) > > > +static void fw_log_firmware_info(const struct firmware *fw, const char *name, struct device *device) > > > +{ > > > + char outbuf[SHA256_STRING_SIZE + 1]; > > > + u8 sha256buf[SHA256_DIGEST_SIZE]; > > > > Nit, these are big, are you _SURE_ you can put them on the stack ok? > > Why not dynamically allocate them? > > > > Well, those arrays are not that big? First one is 65 bytes and other one 32. And how far down in the stack are you when a driver is requesting firmware to be loaded? Usually pretty deep :( > Although now that I looked again at the header, there is SHA256_BLOCK_SIZE > define for string size, so I will change SHA256_STRING_SIZE to that instead. You are already dynamically allocating memory, just do it for all of these please so we don't have to go fix this in a few years when some codepath from a driver is found to have blown up the stack for this debug information. thanks, greg k-h
On 2/24/2023 1:54 PM, Amadeusz Sławiński wrote: > On 2/24/2023 1:46 PM, Greg Kroah-Hartman wrote: >> On Fri, Feb 24, 2023 at 09:19:18PM +0100, Amadeusz Sławiński wrote: >>> Enable dynamic-debug logging of firmware filenames and SHA256 checksums >>> to clearly identify the firmware files that are loaded by the system. >>> >>> Example output: >>> [ 34.944619] firmware_class:_request_firmware: i915 0000:00:02.0: >>> Loaded FW: i915/kbl_dmc_ver1_04.bin, sha256: >>> 2cde41c3e5ad181423bcc3e98ff9c49f743c88f18646af4d0b3c3a9664b831a1 >>> [ 48.155884] firmware_class:_request_firmware: snd_soc_avs >>> 0000:00:1f.3: Loaded FW: intel/avs/cnl/dsp_basefw.bin, sha256: >>> 43f6ac1b066e9bd0423d914960fbbdccb391af27d2b1da1085eee3ea8df0f357 >>> [ 49.579540] firmware_class:_request_firmware: snd_soc_avs >>> 0000:00:1f.3: Loaded FW: intel/avs/rt274-tplg.bin, sha256: >>> 4b3580da96dc3d2c443ba20c6728d8b665fceb3ed57223c3a57582bbad8e2413 >>> [ 49.798196] firmware_class:_request_firmware: snd_soc_avs >>> 0000:00:1f.3: Loaded FW: intel/avs/hda-8086280c-tplg.bin, sha256: >>> 5653172579b2be1b51fd69f5cf46e2bac8d63f2a1327924311c13b2f1fe6e601 >>> [ 49.859627] firmware_class:_request_firmware: snd_soc_avs >>> 0000:00:1f.3: Loaded FW: intel/avs/dmic-tplg.bin, sha256: >>> 00fb7fbdb74683333400d7e46925dae60db448b88638efcca0b30215db9df63f >>> >>> Reviewed-by: Russ Weight <russell.h.weight@intel.com> >>> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> >>> Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com> >>> --- >>> drivers/base/firmware_loader/main.c | 45 ++++++++++++++++++++++++++++- >>> 1 file changed, 44 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/base/firmware_loader/main.c >>> b/drivers/base/firmware_loader/main.c >>> index 017c4cdb219e..a6e1fb10763d 100644 >>> --- a/drivers/base/firmware_loader/main.c >>> +++ b/drivers/base/firmware_loader/main.c >>> @@ -791,6 +791,47 @@ static void fw_abort_batch_reqs(struct firmware >>> *fw) >>> mutex_unlock(&fw_lock); >>> } >>> +#if defined(DEBUG) || defined(CONFIG_DYNAMIC_DEBUG) >>> +#include <crypto/hash.h> >>> +#include <crypto/sha2.h> >>> +#define SHA256_STRING_SIZE (SHA256_DIGEST_SIZE * 2) >>> +static void fw_log_firmware_info(const struct firmware *fw, const >>> char *name, struct device *device) >>> +{ >>> + char outbuf[SHA256_STRING_SIZE + 1]; >>> + u8 sha256buf[SHA256_DIGEST_SIZE]; >> >> Nit, these are big, are you _SURE_ you can put them on the stack ok? >> Why not dynamically allocate them? >> > > Well, those arrays are not that big? First one is 65 bytes and other one > 32. Although now that I looked again at the header, there is > SHA256_BLOCK_SIZE define for string size, so I will change > SHA256_STRING_SIZE to that instead. > >>> + struct shash_desc *shash; >>> + struct crypto_shash *alg; >>> + >>> + alg = crypto_alloc_shash("sha256", 0, 0); >> >> Do we need to select this in the .config as well? >> > > Most likely. > So I'm having a bit of problem here, as something like: diff --git a/drivers/base/firmware_loader/Kconfig b/drivers/base/firmware_loader/Kconfig index 5166b323a0f8..95cf2d8af5c4 100644 --- a/drivers/base/firmware_loader/Kconfig +++ b/drivers/base/firmware_loader/Kconfig @@ -3,6 +3,8 @@ menu "Firmware loader" config FW_LOADER tristate "Firmware loading facility" if EXPERT + select CRYPTO_SHA256 if DYNAMIC_DEBUG + select CRYPTO if DYNAMIC_DEBUG default y help This enables the firmware loading facility in the kernel. The kernel being the most simple potential fix doesn't seem to work due to circular dependencies. Seems like quite a few cryptography accelerators require FW_LOADER and it causes problems. I tried few more things, but none of them seem to work. Any advice on what I can do here? >>> + if (!alg) >>> + return; >>> + >>> + shash = kmalloc(sizeof(*shash) + crypto_shash_descsize(alg), >>> GFP_KERNEL); >> >> kmalloc_array()? >> > > Yes. > And taking one more look, it isn't array allocation but struct followed by VLA used to store additional data, so it will stay as is.
diff --git a/drivers/base/firmware_loader/main.c b/drivers/base/firmware_loader/main.c index 017c4cdb219e..a6e1fb10763d 100644 --- a/drivers/base/firmware_loader/main.c +++ b/drivers/base/firmware_loader/main.c @@ -791,6 +791,47 @@ static void fw_abort_batch_reqs(struct firmware *fw) mutex_unlock(&fw_lock); } +#if defined(DEBUG) || defined(CONFIG_DYNAMIC_DEBUG) +#include <crypto/hash.h> +#include <crypto/sha2.h> +#define SHA256_STRING_SIZE (SHA256_DIGEST_SIZE * 2) +static void fw_log_firmware_info(const struct firmware *fw, const char *name, struct device *device) +{ + char outbuf[SHA256_STRING_SIZE + 1]; + u8 sha256buf[SHA256_DIGEST_SIZE]; + struct shash_desc *shash; + struct crypto_shash *alg; + + alg = crypto_alloc_shash("sha256", 0, 0); + if (!alg) + return; + + shash = kmalloc(sizeof(*shash) + crypto_shash_descsize(alg), GFP_KERNEL); + if (!shash) + goto out_alg; + + shash->tfm = alg; + + if (crypto_shash_digest(shash, fw->data, fw->size, sha256buf) < 0) + goto out_shash; + + for (int i = 0; i < SHA256_DIGEST_SIZE; i++) + sprintf(&outbuf[i * 2], "%02x", sha256buf[i]); + outbuf[SHA256_STRING_SIZE] = 0; + dev_dbg(device, "Loaded FW: %s, sha256: %s\n", name, outbuf); + +out_shash: + kfree(shash); +out_alg: + crypto_free_shash(alg); + +} +#else +static void fw_log_firmware_info(const struct firmware *fw, const char *name, + struct device *device) +{} +#endif + /* called from request_firmware() and request_firmware_work_func() */ static int _request_firmware(const struct firmware **firmware_p, const char *name, @@ -861,11 +902,13 @@ _request_firmware(const struct firmware **firmware_p, const char *name, revert_creds(old_cred); put_cred(kern_cred); - out: +out: if (ret < 0) { fw_abort_batch_reqs(fw); release_firmware(fw); fw = NULL; + } else { + fw_log_firmware_info(fw, name, device); } *firmware_p = fw;