linux-kernel - Re: [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER_

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]

Message-ID: <20220131221333.GR614@gate.crashing.org>
Date:   Mon, 31 Jan 2022 16:13:33 -0600
From:   Segher Boessenkool <segher@...nel.crashing.org>
To:     Nick Desaulniers <ndesaulniers@...gle.com>
Cc:     apinski@...vell.com, Josh Poimboeuf <jpoimboe@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Ingo Molnar <mingo@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Luc Van Oostenryck <luc.vanoostenryck@...il.com>,
        x86@...nel.org, llvm@...ts.linux.dev, linux-sparse@...r.kernel.org,
        linux-kernel@...r.kernel.org, kernel test robot <lkp@...el.com>,
        Nathan Chancellor <nathan@...nel.org>,
        linux-toolchains@...r.kernel.org
Subject: Re: [PATCH] objtool: prefer memory clobber & %= to volatile & __COUNTER__

On Mon, Jan 31, 2022 at 12:45:20PM -0800, Nick Desaulniers wrote:
> On Tue, Jan 25, 2022 at 3:34 PM Segher Boessenkool
> <segher@...nel.crashing.org> wrote:
> >
> > Hi!
> >
> > On Mon, Jan 24, 2022 at 03:26:36PM -0800, Nick Desaulniers wrote:
> > > I'm more confident that we can remove the `volatile` keyword (I was
> > > thinking about adding a new diagnostic to clang to warn that volatile
> > > is redundate+implied for asm goto or inline asm that doesn't have
> > > outputs) though that's not the problem here and will probably generate
> > > some kernel wide cleanup before we could enable such a flag.
> >
> > Its main value is that it would discourage users from thinking volatile
> > is magic.  Seriously worth some pain!
> 
> https://reviews.llvm.org/D118297
> PTAL

""
  Really the volatile asm-qualifier exists only to signal that an asm
  statement should not be DCE'd (when it has outputs but they are unused),
  CSE'd, or LICM'd. It is not a general compiler barrier.

It means that the asm has a side effect (one unknown to the compiler),
so it must be executed in the real machine just where it would be in the
abstract machine.  It *can* be CSEd, it *can* be DCEd, it can even be
optimised by LICM in certain cases: but it has to be executed as often
(and in the same order etc.) in the resulting machine code as it would
be if you single-stepped through the source code by hand.

Those are fine examples if you add "in most cases" (and that they are
just examples, it's not an exhaustive list).

Thanks,


Segher