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: <CAHk-=wgw6C9kgTAmD4r2XWMbaiMRG3ZqCzYs8VptVekuo2g=Qg@mail.gmail.com>
Date:   Thu, 19 Oct 2023 12:07:37 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Uros Bizjak <ubizjak@...il.com>
Cc:     peterz@...radead.org, Nadav Amit <namit@...are.com>,
        "the arch/x86 maintainers" <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andy Lutomirski <luto@...nel.org>,
        Brian Gerst <brgerst@...il.com>,
        Denys Vlasenko <dvlasenk@...hat.com>,
        "H . Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH v2 -tip] x86/percpu: Use C for arch_raw_cpu_ptr()

On Thu, 19 Oct 2023 at 11:49, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> Honestly, I've actually never seen gcc rematerialize anything at all.
>
> I really only started worrying about remat issues in a theoretical
> sense, and because I feel it would be relatively *easy* to do for
> something where the source is a load.

.. I started looking around, since I actually have gcc sources around.

At least lra-remat.cc explicitly says

   o no any memory (as access to memory is non-profitable)

so if we could just *rely* on that, it would actually allow us to use
memory ops without the volatile.

That would be the best of all worlds, of course.

I do have clang sources too, but I've looked at gcc enough that I at
least can do the "grep and look for patterns" and tend to have an idea
of what the passes are. Clang, not so much.

>From my "monkey see patterns" check, it does look like clang mainly
just rematerializes immediates (and some address generation), but also
memory accesses without a base register (allowing a "base register" of
(%rip)).

See X86InstrInfo::isReallyTriviallyReMaterializable() in case anybody cares.

So it does look like clang might actually rematerialize exactly percpu
loads with a constant address, and my "those are easy to
rematerialize" worry may have been correct.

HOWEVER, I'd like to once again say that I know so little about llvm
that my "monkey with 'grep' and some pattern matching ability" thing
really means that I'm just guessing.

Now, PeterZ is obviously worried about even just CSE and re-ordering,
so remat isn't the *only* issue. I do agree that we've had 'volatile'
on many of the asms possibly hiding any issues for the last five
years.

                   Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ