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: <842d430e0df97933914c8f743e7ee226eccb3d3a.camel@surriel.com>
Date: Thu, 05 Jun 2025 20:03:37 -0400
From: Rik van Riel <riel@...riel.com>
To: Nadav Amit <nadav.amit@...il.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 Fri, 2025-06-06 at 01:45 +0300, Nadav Amit wrote:
> 
> 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.

The documentation strongly suggests that RAR_INFO.TableMaxIndex
is architecturally determined, and always 64 on Sapphire Rapids.

I'm not sure we want code to handle a case the Intel documentation
seems to suggest cannot exist. Maybe somebody from Intel has
some firmer ideas here?

> 
> 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.

Grabbing the value of rar_max_payloads from early_init_intel()
might make sense, since it is supposed to be a system-wide
value, and not a per CPU thing.

That seems like it would solve data race issues?

> 
> [ BTW: further regarding patch 4, it seems cleaner to call
>   rar_cpu_init() from Intel specific code like init_intel() ? ]
> 
Good idea, I'll move the call there.

> Just sharing my thoughts (and further clarifying them),
> 
I appreciate the comments and suggestions!

Now that the code seems to (finally) work reliably,
I should have a faster turnaround time incorporating
people's suggestions, too.

-- 
All Rights Reversed.