linux-kernel - Re: [PATCH v3 1/8] platform/x86/intel/ifs: Reorganize driver data

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fc45ace6-546c-59cd-016d-906b6bcb1831@redhat.com>
Date:   Thu, 16 Mar 2023 10:43:17 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     "Joseph, Jithu" <jithu.joseph@...el.com>, markgross@...nel.org
Cc:     tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
        dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
        gregkh@...uxfoundation.org, rostedt@...dmis.org,
        ashok.raj@...el.com, tony.luck@...el.com,
        linux-kernel@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        patches@...ts.linux.dev, ravi.v.shankar@...el.com,
        thiago.macieira@...el.com, athenas.jimenez.gonzalez@...el.com,
        sohil.mehta@...el.com
Subject: Re: [PATCH v3 1/8] platform/x86/intel/ifs: Reorganize driver data

Hi,

On 3/13/23 22:34, Joseph, Jithu wrote:
> 
> 
> On 3/13/2023 7:46 AM, Hans de Goede wrote:
>> Hi Jithu,
>>
>> On 3/1/23 02:59, Jithu Joseph wrote:
> 
>>>  
>>> +struct ifs_const_data {
>>> +	int	integrity_cap_bit;
>>> +	int	test_num;
>>> +};
>>> +
>>
>> This is a description of the specific capabilties / bits of
>> the IFS on e.g. Saphire Rapids, so please name this appropriately
>> for example:
>>
>> struct ifs_hw_caps  {
>> 	int	integrity_cap_bit;
>> 	int	test_num;
>> };
> 
> This can be renamed to ifs_test_caps as it holds test specific fields.

Ack.

>>
>> You got this exactly the wrong way around, there should be a single
>>
>> static const struct ifs_hw_caps saphire_rapids_caps = {
>> 	.integrity_cap_bit = MSR_INTEGRITY_CAPS_PERIODIC_BIST_BIT,
>> 	.test_num = 0,
>> };
>>
>> And then struct ifs_device { } should have a "const struct ifs_hw_caps *hw_caps"
>> which gets initialized to point to &saphire_rapids_caps. So that your const
>> data is actually const.
>>
>> Where as since the r/w data's lifetime is couple to the misc-device lifetime
>> there is no need to dynamically allocate it just keep that embedded, so that
>> together you get:
> 
> Noted 
> 
>>
>> struct ifs_device {
>> 	const struct ifs_hw_caps *hw_caps;
>> 	struct ifs_data data;
>> 	struct miscdevice misc;
>> };
>>
> 
> The initialization portion, taking into account your suggestion above, translates to:

Yes, assuming we go with 1 ifs_device per test type.

Regards,

Hans


> static const struct ifs_test_caps scan_test = {
> 	.integrity_cap_bit = MSR_INTEGRITY_CAPS_PERIODIC_BIST_BIT,
> 	.test_num = IFS_TYPE_SAF,
> };
> 
> static const struct ifs_test_caps array_test = {
> 	.integrity_cap_bit = MSR_INTEGRITY_CAPS_ARRAY_BIST_BIT,
> 	.test_num = IFS_TYPE_ARRAY_BIST,
> };
> 
> static struct ifs_device ifs_devices[] = {
> 	[IFS_TYPE_SAF] = {
> 		.test_caps = &scan_test,
> 		.misc = {
> 			.name = "intel_ifs_0",
> 			.minor = MISC_DYNAMIC_MINOR,
> 			.groups = plat_ifs_groups,
> 		},
> 	},
> 	[IFS_TYPE_ARRAY_BIST] = {
> 		.test_caps = &array_test,
> 		.misc = {
> 			.name = "intel_ifs_1",
> 			.minor = MISC_DYNAMIC_MINOR,
> 			.groups = plat_ifs_array_groups,
> 		},
> 	},
> };
> 
> Jithu
>