Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <8fb5dea0-9ce6-a17c-1253-64a43c86c82c@intel.com>
Date:   Tue, 17 May 2022 09:16:50 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Firefox/91.0 Thunderbird/91.8.1
Subject: Re: [PATCH v20 3/5] fpga: m10bmc-sec: expose max10 flash update count
Content-Language: en-US
To:     Xu Yilun <yilun.xu@intel.com>
CC:     <mdf@kernel.org>, <hao.wu@intel.com>, <lee.jones@linaro.org>,
        <linux-fpga@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <trix@redhat.com>, <marpagan@redhat.com>, <lgoncalv@redhat.com>,
        <matthew.gerlach@linux.intel.com>,
        <basheer.ahmed.muddebihal@intel.com>, <tianfei.zhang@intel.com>
References: <20220516234941.592886-1-russell.h.weight@intel.com>
 <20220516234941.592886-4-russell.h.weight@intel.com>
 <20220517041310.GA40711@yilunxu-OptiPlex-7050>
From:   Russ Weight <russell.h.weight@intel.com>
In-Reply-To: <20220517041310.GA40711@yilunxu-OptiPlex-7050>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?WnA3ek5yNWcwYklRODFnRkw1V3RnblVBd1dSd3QwVGtBTWVEMVVFYm1WWmhm?=
 =?utf-8?B?NlMxaWt3RGl1bkpoV3JQeEo1a1dRbHBJZHhOalkzS0dXYkdGbS90eHB3TGIy?=
 =?utf-8?B?eWV1aXBJbHpOMGxrMFN5YWs0WGdVZUtqVXBvZlRkNnlPK1pWUEZaZG9jaU9B?=
 =?utf-8?B?VVl5c3hhZjY2UVNSV3duRm0wTDJYTW9JRlZickUxNWNJa0lCeUMzKzBieHFC?=
 =?utf-8?B?VmFUeERML1pNdnJMRHNkNlJ1VnhsMmJnV3lMYkMyUWhERWo2M2Zrc2YrYVNF?=
 =?utf-8?B?dmI5TU1lWlZBWUhaT2VxUU0wakpvS2IxM0pjbExVWUlWekpjbHpHU1JMWTFa?=
 =?utf-8?B?Y0tlRnRkVG9FSHV4Mk4xREdyTzdEa2xtaDZtZkdXMEdweDlpK1NvZlRMUkZ2?=
 =?utf-8?B?NzNiSVU0eVlGekE1OE4wSm1lZDE4VUlPcVQybzIzUCtWWjdWTkU5eFBWSlNI?=
 =?utf-8?B?alRzZzF5NVRkMTI5bzRBb0JJOE5nd1BwMnR0d3FCNXZMeklSQ3hCcWxIVm5X?=
 =?utf-8?B?c250QnZJd1I2WUdOMVJxM1FQZ29EOEF6eHZZbjJ4T3dDOXhQY2ZtRWFCQi9S?=
 =?utf-8?B?TVVYT2xlajhTOTBYZkpwLzVMM00yYXVPZy9DR1BzdG5RYmdkc1lIeDJMRjdL?=
 =?utf-8?B?bkorSWRhYWUxbzNHb0R6VzFVemFaTWh1VVFuTkwxbzlwZ0VhV3VLYTRYS21N?=
 =?utf-8?B?OUIwL3RiVTZhWUpPdVdod0FLWUY3ZHRLWXgzM1c5bjIyK2UrRzNyeVpzM2J1?=
 =?utf-8?B?WDRucGNkWjVxRXNXV0xjbWRMOUcrNFE4dXNXSEoyRDBBbzBGOW96M3Q1TFox?=
 =?utf-8?B?UU9xVmR2K1luaVdPbldGWitnTnV4aGVZN1gvQ2QvL2hsbFhJTllLbFloK1Fw?=
 =?utf-8?B?aXcxR1NwU1BaWnZUK1JUY2cyd1RmQ3V0KzNkT1JxOWg1YkZiNWdnZ1BlZ1dK?=
 =?utf-8?B?aHdtZlRQNEhReTBlckkxK0xDaFhjZGZMTkx4RjVhNWE1MTVhVVhQdzdRdC9v?=
 =?utf-8?B?WDBBZEI4MHdtVVZFUFFxUUdMTWFtR1M1TTJOSVdycmhyQ3ZRYzl4UExHWDlL?=
 =?utf-8?B?akdoNVdRbzY3c3BaOVE3elRPOVVKY0treGVFQ0lON3NZc1pPTEsyZkNBNWN3?=
 =?utf-8?B?RU5PTHlVazJFYzQwcFhDdGRRSWIzY0NrN2s1c21nVWRoc2VpbDVuQmRrSFBR?=
 =?utf-8?B?MEhjYzVFVTBDbk42MjFkNkZuYTUwb1RhMjc5aTNlVWtFbndXcHFDY3h5MC9s?=
 =?utf-8?B?dGhrd1lIYU9ZZG04K0Q0RjBRSTZlSE9Lb3BBWXJOL2RjU250d3RGa2NpWkt2?=
 =?utf-8?B?eWN4emtxam9PTWEwQXp6bG5lWjM4dDE5ODQ5Q0w0TlJOeEdTWFhUTVBxZmxo?=
 =?utf-8?B?T0h6WWhqZlFkL3BaM2dseDJTREtOY2ZjRllwVzFqVTRqdDRxOGo0aHFGT3JS?=
 =?utf-8?B?T3VPQ2l0dXFjQkk5a3krUkh0MmNYYTlRVm1McDI0Zng4WUxLM0Qxa3pPejJO?=
 =?utf-8?B?TEdOOW9XVFQ3VGFFamtHOXUwWCt4UStFVXBMK3o4REMwcDlXMHZocHgwM3pP?=
 =?utf-8?B?cWJLai9IRXhhMTF5OHBLVk9VMVRROXJnbktIa2JCY3dZU3FrM0dNVzd0aFZM?=
 =?utf-8?B?QW5MM0JpOUpNbXBic3dPWnNCZFVESnBuc2pyeU5PZkxObWdDZU1iOEk3ckhM?=
 =?utf-8?B?NlY5WDI5eUMrWXdOMExSdC9ENmZmSitCUXZFc1hzZU1wdVJaVHVNZmJjSlhF?=
 =?utf-8?B?d0t1bjVBODZ3TmRXNncvcHJuU0YreWRBWldPK2xTelpiZEtLSzZScnlVcEpu?=
 =?utf-8?B?ZlJaLzFDOUNQeGxoM2RGRXpWejZpQXhjaEpLT2NFRlM0NUdOWEtBWnZZNmhR?=
 =?utf-8?B?MlU4Nkc2TEpKL1REbnc1dmxid0RQK1hGd0VxdW1YTFB3Zk9ZNEFIYXRGek5N?=
 =?utf-8?B?WllaYSs0Z3hHNTdXRXZBWWJlSjI1UVdJZWl1VUtTc1Q2bHpyTHc2QmJyWkFQ?=
 =?utf-8?B?TDNxd25PSjZuVk5lTWI4OWVML1VwZ2lqcjdsL0h6cFVOODVWRG00VjRybGF0?=
 =?utf-8?B?Yk1ZWjdSMjhSVmZ4Q2U1UHViQkZxOVBqRUNJMkhLYXo5MTVZL3BEZW85c2xQ?=
 =?utf-8?B?cDNCMmJncm1UTC9qdmoveVdGbVZnVE92bDF6K29zOVUzaWtPU1JoczhJM2FN?=
 =?utf-8?B?QUs3bldaNlVrS2F2UkZGdkVEWlpYcW1WZVdmcE1WNmtEenJaOEExdXd1ZFN5?=
 =?utf-8?B?RVp4WDZTOHE5Zms3MFB5TUJ5SmVzNmU2WVpUaE5rWFZ5S0xOQmFkUkJDWFlU?=
 =?utf-8?B?a0tGcDFVTXVqMlJ5SnE1STRXSnN1Z01tNnhUS1dJT2FkR0s0blpJTDVDdlpP?=
 =?utf-8?Q?yxilNO8CGwHgkKPY=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 924fd454-e764-4fc2-5d11-08da3820a884
X-MS-Exchange-CrossTenant-AuthSource: DM5PR11MB1899.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2022 16:16:54.5420
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: kw14KzsBDNgsfOr3ZvkVGFEbai6tQIqRW9Hw3eiGk/q9Jk3ekfmWeZOuUL4AXSDgx2akb7ATsEixtGdp6Aguu4EMa/r03TUZwfJUMOAgeqU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2824
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE,
	T_SCC_BODY_TEXT_LINE autolearn=unavailable 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


On 5/16/22 21:13, Xu Yilun wrote:
> On Mon, May 16, 2022 at 04:49:39PM -0700, Russ Weight wrote:
>> Extend the MAX10 BMC Secure Update driver to provide a sysfs file to
>> expose the flash update count.
>>
>> Signed-off-by: Russ Weight <russell.h.weight@intel.com>
>> Reviewed-by: Tom Rix <trix@redhat.com>
>> ---
>> v20:
>>   - No change
>> v19:
>>   - Change "card bmc" naming back to "m10 bmc" naming to be consistent
>>     with the parent driver.
>> v18:
>>   - No change
>> v17:
>>   - Update the Date and KernelVersion for the ABI documentation to Jul 2022
>>     and 5.19 respectively.
>>   - Change "m10bmc" in symbol names to "cardbmc" to reflect the fact that the
>>     future devices will not necessarily use the MAX10.
>> v16:
>>   - No Change
>> v15:
>>   - Updated the Dates and KernelVersions in the ABI documentation
>> v14:
>>   - No change
>> v13:
>>   - Updated ABI documentation date and kernel version
>> v12:
>>   - Updated Date and KernelVersion fields in ABI documentation
>> v11:
>>   - No change
>> v10:
>>   - Changed the path expression in the sysfs documentation to
>>     replace the n3000 reference with something more generic to
>>     accomodate other devices that use the same driver.
>> v9:
>>   - Rebased to 5.12-rc2 next
>>   - Updated Date and KernelVersion in ABI documentation
>> v8:
>>   - Previously patch 3/6, otherwise no change
>> v7:
>>   - Updated Date and KernelVersion in ABI documentation
>> v6:
>>   - Changed flash_count_show() parameter list to achieve
>>     reverse-christmas tree format.
>>   - Added WARN_ON() call for (FLASH_COUNT_SIZE / stride) to ensure
>>     that the proper count is passed to regmap_bulk_read().
>> v5:
>>   - Renamed sysfs node user_flash_count to flash_count and updated the
>>     sysfs documentation accordingly.
>> v4:
>>   - Moved the sysfs file for displaying the flash count from the
>>     FPGA Security Manager class driver to here. The
>>     m10bmc_user_flash_count() function is removed and the
>>     functionality is moved into a user_flash_count_show()
>>     function.
>>   - Added ABI documentation for the new sysfs entry
>> v3:
>>   - Changed: iops -> sops, imgr -> smgr, IFPGA_ -> FPGA_, ifpga_ to fpga_
>>   - Changed "MAX10 BMC Secure Engine driver" to "MAX10 BMC Secure Update
>>     driver"
>>   - Removed wrapper functions (m10bmc_raw_*, m10bmc_sys_*). The
>>     underlying functions are now called directly.
>> v2:
>>   - Renamed get_qspi_flash_count() to m10bmc_user_flash_count()
>>   - Minor code cleanup per review comments
>>   - Added m10bmc_ prefix to functions in m10bmc_iops structure
>> ---
>>  .../sysfs-driver-intel-m10-bmc-sec-update     |  8 +++++
>>  drivers/fpga/intel-m10-bmc-sec-update.c       | 36 +++++++++++++++++++
>>  2 files changed, 44 insertions(+)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update
>> index 2bb271695e14..1132e39b2125 100644
>> --- a/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update
>> +++ b/Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update
>> @@ -27,3 +27,11 @@ Description:	Read only. Returns the root entry hash for the BMC image
>>  		"hash not programmed".  This file is only visible if the
>>  		underlying device supports it.
>>  		Format: string.
>> +
>> +What:		/sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/flash_count
>> +Date:		Jul 2022
>> +KernelVersion:	5.19
>> +Contact:	Russ Weight <russell.h.weight@intel.com>
>> +Description:	Read only. Returns number of times the secure update
>> +		staging area has been flashed.
>> +		Format: "%u".
>> diff --git a/drivers/fpga/intel-m10-bmc-sec-update.c b/drivers/fpga/intel-m10-bmc-sec-update.c
>> index f9f39d2cfe5b..3f183202de3b 100644
>> --- a/drivers/fpga/intel-m10-bmc-sec-update.c
>> +++ b/drivers/fpga/intel-m10-bmc-sec-update.c
>> @@ -78,7 +78,43 @@ DEVICE_ATTR_SEC_REH_RO(bmc, BMC_PROG_MAGIC, BMC_PROG_ADDR, BMC_REH_ADDR);
>>  DEVICE_ATTR_SEC_REH_RO(sr, SR_PROG_MAGIC, SR_PROG_ADDR, SR_REH_ADDR);
>>  DEVICE_ATTR_SEC_REH_RO(pr, PR_PROG_MAGIC, PR_PROG_ADDR, PR_REH_ADDR);
>>  
>> +#define FLASH_COUNT_SIZE 4096	/* count stored as inverted bit vector */
>> +
>> +static ssize_t flash_count_show(struct device *dev,
>> +				struct device_attribute *attr, char *buf)
>> +{
>> +	struct m10bmc_sec *sec = dev_get_drvdata(dev);
>> +	unsigned int stride, num_bits;
>> +	u8 *flash_buf;
>> +	int cnt, ret;
>> +
>> +	stride = regmap_get_reg_stride(sec->m10bmc->regmap);
>> +	num_bits = FLASH_COUNT_SIZE * 8;
>> +
>> +	flash_buf = kmalloc(FLASH_COUNT_SIZE, GFP_KERNEL);
>> +	if (!flash_buf)
>> +		return -ENOMEM;
>> +
>> +	WARN_ON(FLASH_COUNT_SIZE % stride);
> The same concern here. Stop users from getting the broken value.

Sure - I will change this.

I was using WARN_ON() because it indicates a problem in the device or
the driver itself. It is not really validating information from userspace.

As I understand it, WARN_ON() is used to log such events to the kernel
log. If this isn't an appropriate use of WARN_ON(), then when should I
consider using it?

Thanks,
- Russ
>
>> +	ret = regmap_bulk_read(sec->m10bmc->regmap, STAGING_FLASH_COUNT,
>> +			       flash_buf, FLASH_COUNT_SIZE / stride);
>> +	if (ret) {
>> +		dev_err(sec->dev,
>> +			"failed to read flash count: %x cnt %x: %d\n",
>> +			STAGING_FLASH_COUNT, FLASH_COUNT_SIZE / stride, ret);
>> +		goto exit_free;
>> +	}
>> +	cnt = num_bits - bitmap_weight((unsigned long *)flash_buf, num_bits);
>> +
>> +exit_free:
>> +	kfree(flash_buf);
>> +
>> +	return ret ? : sysfs_emit(buf, "%u\n", cnt);
>> +}
>> +static DEVICE_ATTR_RO(flash_count);
>> +
>>  static struct attribute *m10bmc_security_attrs[] = {
>> +	&dev_attr_flash_count.attr,
>>  	&dev_attr_bmc_root_entry_hash.attr,
>>  	&dev_attr_sr_root_entry_hash.attr,
>>  	&dev_attr_pr_root_entry_hash.attr,
>> -- 
>> 2.25.1