linux-kernel - Re: [PATCH v2 2/4] MIPS: Introduce config options for LLSC availability

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: <83cf475c-86a3-4acb-bc82-d94c66c53779@app.fastmail.com>
Date: Fri, 21 Jun 2024 16:21:49 +0100
From: "Jiaxun Yang" <jiaxun.yang@...goat.com>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: "Thomas Bogendoerfer" <tsbogend@...ha.franken.de>,
 "Jonas Gorski" <jonas.gorski@...il.com>,
 "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/4] MIPS: Introduce config options for LLSC availability



在2024年6月21日六月 下午2:57，Maciej W. Rozycki写道：
> On Fri, 21 Jun 2024, Jiaxun Yang wrote:
>
>> >  I think this ought not to be done in two places independently and the 
>> > pieces in <asm/mach-*/cpu-feature-overrides.h> need to be removed, likely 
>> > in the same change even, *however* not without double-checking whether 
>> > there is not a case among them where a platform actually has LL/SC support 
>> > disabled despite the CPU used there having architectural support for the 
>> > feature.  Otherwise we may end up with a case where a platform has LL/SC 
>> > support disabled via its <asm/mach-*/cpu-feature-overrides.h> setting and 
>> > yet we enable ARCH_SUPPORTS_ATOMIC_RMW or ARCH_HAVE_NMI_SAFE_CMPXCHG for 
>> > it via Kconfig.
>> 
>> IMO it's necessary for platforms who know what are they doing such as ATH25,
>> which we took care in this series.
>> 
>> I'll add a build time assertion to ensure when CONFIG_CPU_HAS_LLSC is selected
>> kernel_uses_llsc is statically 1, so any incorrect overrides can be spotted
>> at build time.
>
>  That might do in the interim as a sanity check, however ultimately the 
> sole reason these <asm/mach-*/cpu-feature-overrides.h> exist (and the 
> `cpu_has_llsc' setting there) is so that a dynamic check at run time is 
> avoided where the result is known from elsewhere beforehand anyway, and 
> your change effectively supersedes the overrides, and therefore they need 
> to be removed.
>
No, overrides are still valid if platform did CPU_MAY_HAVE_LLSC, this is at
least valid for R10000 systems (IP28 decided to opt-out from llsc somehow),
ATH25 (platform made assumption on IP version shipped with CPU), cavium
octeon (platform decided to opt-out llsc for non-SMP build). I'm not confident
with handling them all in Kconfig so I think the best approach so far is to do
build time assertion.

Does anyone reckon the reason behind opt-out LLSC for IP28? As far as I understand
there is no restriction on using LLSC after workaround being applied. If it's purely
performance reason, I think I'll need to move kernel_uses_llsc logic to Kconfig as well.

Thanks
>
>   Maciej

-- 
- Jiaxun