linux-kernel - Re: [PATCH 0/4] arm64: Support the TSO memory model

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] [day] [month] [year] [list]

Date: Thu, 9 May 2024 13:56:36 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: Neal Gompa <neal@...pa.dev>
Cc: Ard Biesheuvel <ardb@...nel.org>,
	Alex Bennée <alex.bennee@...aro.org>,
	Will Deacon <will@...nel.org>, Hector Martin <marcan@...can.st>,
	Marc Zyngier <maz@...nel.org>, Mark Rutland <mark.rutland@....com>,
	Zayd Qumsieh <zayd_qumsieh@...le.com>,
	Justin Lu <ih_justin@...le.com>,
	Ryan Houdek <Houdek.Ryan@...-emu.org>,
	Mark Brown <broonie@...nel.org>, Mateusz Guzik <mjguzik@...il.com>,
	Anshuman Khandual <anshuman.khandual@....com>,
	Oliver Upton <oliver.upton@...ux.dev>,
	Miguel Luis <miguel.luis@...cle.com>,
	Joey Gouly <joey.gouly@....com>,
	Christoph Paasch <cpaasch@...le.com>,
	Kees Cook <keescook@...omium.org>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Baoquan He <bhe@...hat.com>, Joel Granados <j.granados@...sung.com>,
	Dawei Li <dawei.li@...ngroup.cn>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Florent Revest <revest@...omium.org>,
	David Hildenbrand <david@...hat.com>,
	Stefan Roesch <shr@...kernel.io>, Andy Chiu <andy.chiu@...ive.com>,
	Josh Triplett <josh@...htriplett.org>,
	Oleg Nesterov <oleg@...hat.com>, Helge Deller <deller@....de>,
	Zev Weiss <zev@...ilderbeest.net>,
	Ondrej Mosnacek <omosnace@...hat.com>,
	Miguel Ojeda <ojeda@...nel.org>,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Asahi Linux <asahi@...ts.linux.dev>
Subject: Re: [PATCH 0/4] arm64: Support the TSO memory model

On Thu, May 09, 2024 at 06:31:04AM -0600, Neal Gompa wrote:
> On Thu, May 9, 2024 at 5:13 AM Catalin Marinas <catalin.marinas@....com> wrote:
> > I see the impdef hardware TSO options as temporary until CPU
> > implementations catch up to architected FEAT_LRCPC*. Given the problems
> > already stated in this thread, I think such hacks should be carried
> > downstream and (hopefully) will eventually vanish. Maybe those TSO knobs
> > currently make an emulation faster than FEAT_LRCPC* but that's feedback
> > to go to the microarchitects on the implementation (or architects on
> > what other instructions should be covered).
> 
> They cannot ever "vanish" because we are supporting every Mx platform
> back to the first one. The M1 series will never have FEAT_LRCPC.

Well, you missed "eventually". It depends on the timeline you have in
mind but, say, 15 years from now there may not be many M1s around to be
worth maintaining these patches out-of-tree (and they don't make sense
in-tree either because of the lack of standardisation).

> I do not think it is unreasonable to support this method when we know
> what the CPU platform is and FEAT_LRCPC does not exist.

If you want a portable emulator, you better start supporting FEAT_LRCPC*
(I think FEX does this), ideally detected at run-time with a fallback to
RCsc. Whether, additionally, you want to support the non-portable Apple
TSO with out-of-tree patches, it's up to you.

-- 
Catalin