linux-kernel - Re: [PATCH v3 6/8] platform/x86/intel/ifs: Implement Array BIST test

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: <9dde72aa-a28d-2b0e-7b90-6b1996dbf202@intel.com>
Date:   Mon, 13 Mar 2023 09:37:32 -0700
From:   "Joseph, Jithu" <jithu.joseph@...el.com>
To:     Hans de Goede <hdegoede@...hat.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 6/8] platform/x86/intel/ifs: Implement Array BIST test

Hans,

Thank-you very much for the review.

On 3/13/2023 9:24 AM, Hans de Goede wrote:


>>  
>> +#define SPINUNIT 100 /* 100 nsec */
>> +static atomic_t array_cpus_out;
> 
> This variable is only inc-ed + read, it is never reset to 0
> so the "while (atomic_read(t) < all_cpus)"
> check only works for the first test run.
> 

It is reset to zero as annotated below. Let me know if this doesn't address your concern.

> Also even static atomic_t variables must be initialized, you cannot
> assume that using using zeroed mem is a valid value for an atomic_t.
> 
> And this is also shared between all smt pairs, so if 2 "real"
> CPU cores with both 2 sibblings are asked to run IFS tests at
> the same time, then array_cpus_out will get increased 4 times
> in total, breaking the wait_for_sibbling loop as soon as
> the counter reaches 2, so before the tests are done.

Only one IFS test is allowed at a time. This is done using "ifs_sem" defined in sysfs.c

...

>> +static void ifs_array_test_core(int cpu, struct device *dev)
>> +{
>> +	union ifs_array command = {};
>> +	bool timed_out = false;
>> +	struct ifs_data *ifsd;
>> +	unsigned long timeout;
>> +
>> +	ifsd = ifs_get_data(dev);
>> +
>> +	command.array_bitmask = ~0U;
>> +	timeout = jiffies + HZ / 2;
>> +
>> +	do {
>> +		if (time_after(jiffies, timeout)) {
>> +			timed_out = true;
>> +			break;
>> +		}
>> +		atomic_set(&array_cpus_out, 0);

The above line is where the zero initialization happens before every test.

>> +		stop_core_cpuslocked(cpu, do_array_test, &command);
>> +
>> +		if (command.ctrl_result)
>> +			break;
>> +	} while (command.array_bitmask);
>> +
>> +	ifsd->scan_details = command.data;
>> +
>> +	if (command.ctrl_result)
>> +		ifsd->status = SCAN_TEST_FAIL;
>> +	else if (timed_out || command.array_bitmask)
>> +		ifsd->status = SCAN_NOT_TESTED;
>> +	else
>> +		ifsd->status = SCAN_TEST_PASS;
>> +}

Jithu