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

Date: Wed, 01 May 2024 17:16:32 -0700
From: Zayd Qumsieh <zayd_qumsieh@...le.com>
To: Will Deacon <will@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>, 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>, Ard Biesheuvel <ardb@...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, 11 Apr 2024 14:28:54 +0100,
Will Deacon <will@...nel.org> wrote:
> P.S. I briefly pondered the idea of the kernel toggling the bit in the
> ELF loader when e.g. it sees an x86 machine type but I suspect that
> doesn't really help with existing emulators and you'd still need a way
> to tell the emulator whether or not it was enabled.

This seems promising to me. What do people think of adding an opt-in argument,
option, or similar to binfmt that allows users to mark certain file formats as
"must run under TSO"? And then, the kernel would set the TSO bit when invoking
the interpreter for those file formats. If an emulator decides to create a
non-CPU-emulation thread, then it can use a prctl to disable TSO and switch to
the default ARM memory model. Note that this prctl wouldn't be allowed to
enable TSO - it would only disable it. This way, it is much harder for a
faulty application to be made that relies on TSO, since enabling of TSO is
only done via a binfmt handler that the user must explicitly opt into.

It is true that existing emulators wouldn't be able to benefit from this, but
that's the case no matter the activation mechanism. We can, however, expose a
prctl to get the memory model, so emulators can detect if TSO was enabled for
their threads.

To summarize, I propose two prctls (similar to the ones in the current revision
of the patch series). One to switch from the TSO memory model to the default
ARM one (this is a one-way street). And another to query the current memory
model.

Thanks,
Zayd

P.S. I forgot to CC you in my most recent email to Marc Zyngier just now. 
Sorry, I'm quite new to using mailing lists.