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: <20210609171419.GI18427@gate.crashing.org>
Date:   Wed, 9 Jun 2021 12:14:19 -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 06:13:00PM +0200, Marco Elver wrote:
> On Wed, 9 Jun 2021 at 17:33, Segher Boessenkool
> <segher@...nel.crashing.org> wrote:
> [...]
> > > 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.
> 
> Statement attributes can apply to anything -- Clang has had them apply
> to non-empty statements for a while.

First off, it is not GCC's problem if LLVM decides to use a GCC
extension in some non-compatible way.

It might be possible to extend statement attributes to arbitrary
statement expressions, or some subset of statement expressions, but that
then has to be written down as well; it isn't obvious at all what this
woould do.

> In fact, since C++20 [3], GCC will have to support statement
> attributes on non-empty statements, so presumably the parsing logic
> should already be there.
> [3] https://en.cppreference.com/w/cpp/language/attributes/likely

C++ attributes have different syntax *and semantics*.  With GCC
attributes it isn't clear what statement something belongs to (a
statement can contain a statement after all).

C++ requires all unknown attributes to be ignored without error, so can
this be useful at all here?

> > Some new builtin seems to fit the requirements better?  I haven't looked
> > too closely though.
> 
> I had a longer discussion with someone offline about it, and the
> problem with a builtin is similar to the "memory_order_consume
> implementation problem" -- you might have an expression that uses the
> builtin in some function without any control, and merely returns the
> result of the expression as a result. If that function is in another
> compilation unit, it then becomes difficult to propagate this
> information without somehow making it part of the type system.
> Therefore, by using a statement attribute on conditional control
> statements, we do not even have this problem. It seems cleaner
> syntactically than having a __builtin_() that is either approximate,
> or gives an error if used in the wrong context.

You would use the builtin to mark exactly where you are making the
control dependency.

(And what is a "conditional control statement"?  Yes of course I can
imagine things, but that is not good enough at all).

> Hence the suggestion for a very simple attribute, which also
> side-steps this problem.

And introduces many more problems :-(


Segher