linux-kernel - Re: [RFC PATCH v3 5/7] x86/mm: Introduce Remote Action Request

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: <51570690-D1B2-48EE-96EE-5C90B93C7067@gmail.com>
Date: Fri, 6 Jun 2025 01:45:54 +0300
From: Nadav Amit <nadav.amit@...il.com>
To: Rik van Riel <riel@...riel.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
 kernel-team@...a.com,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 luto@...nel.org,
 peterz@...radead.org,
 Borislav Petkov <bp@...en8.de>,
 the arch/x86 maintainers <x86@...nel.org>,
 Sean Christopherson <seanjc@...gle.com>,
 Thomas Gleixner <tglx@...utronix.de>,
 Yu-cheng Yu <yu-cheng.yu@...el.com>
Subject: Re: [RFC PATCH v3 5/7] x86/mm: Introduce Remote Action Request

> On 5 Jun 2025, at 22:40, Rik van Riel <riel@...riel.com> wrote:
> 
> On Thu, 2025-06-05 at 21:54 +0300, Nadav Amit wrote:
>> Just few small things that jump out…
>> 
>>> On 5 Jun 2025, at 19:35, Rik van Riel <riel@...riel.com> wrote:
>>> 
>>> 
>>> On 5 Jun 2025, at 19:35, Rik van Riel <riel@...riel.com> wrote:
>>> 
>>> +void rar_cpu_init(void)
>>> +{
>>> +	u64 r;
>>> +	u8 *bitmap;
>>> +	int max_payloads;
>>> +	int this_cpu = smp_processor_id();
>>> +
>>> +	cpumask_clear(&per_cpu(rar_cpu_mask, this_cpu));
>>> +
>>> +	/* The MSR contains N defining the max [0-N] rar payload
>>> slots. */
>>> +	rdmsrl(MSR_IA32_RAR_INFO, r);
>>> +	max_payloads = (r >> 32) + 1;
>>> +
>>> +	/* If this CPU supports less than RAR_MAX_PAYLOADS, lower
>>> our limit. */
>>> +	if (max_payloads < rar_max_payloads)
>>> +		rar_max_payloads = max_payloads;
>> 
>> Unless I am missing something, this looks very racy.
>> 
> All the CPUs in the system should support the same
> number rar_max_payloads, since they share the same
> rar_action table.
> 

Usually you don’t want even benign data-races because it might cause
tools to shout for no reason. So you would want to assist both other
people and tools such as KCSAN by marking such accesses with
data_race().

However, I think perhaps the bigger issue is that you want to assume
all cores have the same RAR settings, and right now it might be a bit
inconsistent.

So you may want to do some initial checks on the BSP as for
whether RAR is supported and what rar_max_payloads is (e.g., in
bsp_init_intel() ). And then on each AP, in something like 
init_intel() you’d call setup_clear_cpu_cap() to disable RAR if any
CPU's max_payloads is different than the BSP.

[ BTW: further regarding patch 4, it seems cleaner to call
  rar_cpu_init() from Intel specific code like init_intel() ? ]

Just sharing my thoughts (and further clarifying them),
Nadav