linux-kernel - Re: [RFC PATCH 11/20] x86/virt/seamldr: Abort updates if errors occurred midway

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: <aEZI63RZ3t28G/Ft@intel.com>
Date: Mon, 9 Jun 2025 10:37:31 +0800
From: Chao Gao <chao.gao@...el.com>
To: Nikolay Borisov <nik.borisov@...e.com>
CC: <linux-coco@...ts.linux.dev>, <x86@...nel.org>, <kvm@...r.kernel.org>,
	<seanjc@...gle.com>, <pbonzini@...hat.com>, <eddie.dong@...el.com>,
	<kirill.shutemov@...el.com>, <dave.hansen@...el.com>,
	<dan.j.williams@...el.com>, <kai.huang@...el.com>,
	<isaku.yamahata@...el.com>, <elena.reshetova@...el.com>,
	<rick.p.edgecombe@...el.com>, Farrah Chen <farrah.chen@...el.com>, "Kirill A.
 Shutemov" <kirill.shutemov@...ux.intel.com>, Dave Hansen
	<dave.hansen@...ux.intel.com>, Thomas Gleixner <tglx@...utronix.de>, "Ingo
 Molnar" <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, "H. Peter Anvin"
	<hpa@...or.com>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 11/20] x86/virt/seamldr: Abort updates if errors
 occurred midway

>>   static void ack_state(void)
>>   {
>> -	if (atomic_dec_and_test(&tdp_data.thread_ack))
>> -		set_state(tdp_data.state + 1);
>> +	if (atomic_dec_and_test(&tdp_data.thread_ack)) {
>> +		/*
>> +		 * If an error occurred, abort the update by skipping to
>> +		 * the final state
>> +		 */
>> +		if (atomic_read(&tdp_data.failed))
>> +			set_state(TDP_DONE);
>> +		else
>> +			set_state(tdp_data.state + 1);
>> +	}
>>   }
>>   /*
>> @@ -285,6 +294,9 @@ static int do_seamldr_install_module(void *params)
>>   			default:
>>   				break;
>>   			}
>> +
>> +			if (ret)
>> +				atomic_inc(&tdp_data.failed);
>
>Should there be some explicit ordering requirement between setting an error
>and reading it in ack_state by a different CPU?

Only the last CPU that calls ack_state() will change the global state, either
advancing to the next state or setting it to TDP_DONE on error. so, we only
need to ensure that the last CPU can see the error. This is guaranteed because
the error is set before the call to ack_state().

+			if (ret)
+				atomic_inc(&tdp_data.failed);
			ack_state();