linux-kernel - Re: [RFC] LKMM: Add volatile

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: <20210609153133.GF18427@gate.crashing.org>
Date:   Wed, 9 Jun 2021 10:31:33 -0500
From:   Segher Boessenkool <segher@...nel.crashing.org>
To:     Marco Elver <elver@...gle.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        "Paul E. McKenney" <paulmck@...nel.org>,
        Alexander Monakov <amonakov@...ras.ru>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jakub Jelinek <jakub@...hat.com>,
        Alan Stern <stern@...land.harvard.edu>,
        Will Deacon <will@...nel.org>,
        Andrea Parri <parri.andrea@...il.com>,
        Boqun Feng <boqun.feng@...il.com>,
        Nick Piggin <npiggin@...il.com>,
        David Howells <dhowells@...hat.com>,
        Jade Alglave <j.alglave@....ac.uk>,
        Luc Maranget <luc.maranget@...ia.fr>,
        Akira Yokosawa <akiyks@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-toolchains@...r.kernel.org,
        linux-arch <linux-arch@...r.kernel.org>
Subject: Re: [RFC] LKMM: Add volatile_if()

On Wed, Jun 09, 2021 at 02:44:08PM +0200, Marco Elver wrote:
> On Tue, 8 Jun 2021 at 17:30, Segher Boessenkool
> <segher@...nel.crashing.org> wrote:
> > This needs some work.
> 
> There is a valid concern that something at the level of the memory
> model requires very precise specification in terms of language
> semantics and not generated code.

Yup, exactly.  Especially because the meaning of generated code is hard
to describe, and even much more so if you do not limit yourself to a
single machine architecture.

> Otherwise it seems difficult to get
> compiler folks onboard.

It isn't just difficult to get us on board without it, we know it just
is impossible to do anything sensible without it.

> And coming up with such a specification may
> take a while,

Yes.

> especially if we have to venture in the realm of the
> C11/C++11 memory model while still trying to somehow make it work for
> the LKMM. That seems like a very tricky maze we may want to avoid.

Well, you only need to use the saner parts of the memory model (not the
full thing), and extensions are fine as well of course.

> An alternative design would be to use a statement attribute to only
> enforce (C) ("__attribute__((mustcontrol))" ?).

Statement attributes only exist for empty statements.  It is unclear how
(and if!) we could support it for general statements.

Some new builtin seems to fit the requirements better?  I haven't looked
too closely though.


Segher