linux-kernel - Re: [GIT PULL] x86/asm updates for v5.10

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: <CAHk-=wgBHgmAoLG9A0b-2_2ZiL_OaXLyO2pbKOHm=u93NttSBQ@mail.gmail.com>
Date:   Mon, 12 Oct 2020 12:03:18 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Uros Bizjak <ubizjak@...il.com>
Cc:     Borislav Petkov <bp@...e.de>, x86-ml <x86@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] x86/asm updates for v5.10

On Mon, Oct 12, 2020 at 11:56 AM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> I also find that clang generates code that uses the high byte
> registers, although again, that's not from any knowledge of clang
> internals, and just by looking at my kernel image disassembly.
>
> So yes, it _may_ all be just peepholes, but it's not obvious that this
> is all safe.

The clang use I find seems to be _purely_ for variations of "mov", and
only ever with the high register as a source.

So yes, that one looks very much like a peephole optimization where
clang just recognizes patterns line

     X = (y >> 8) & 0xff;

and uses a "movzbl %*h,xyz" for it.

Gcc actually seems to use high registers more, but the extended use
seems to be bit test (and set) operations that also may be simply
peepholes.

So yes, from code generation patterns it does look likely that neither
compiler actually considers the high registers to be truely
independent entities, and thus quite likely that you'd never find
concurrent mixed use.

But that really seems to be an implementation issue rather than
something we should necessarily rely on, unless we have a stronger
statement from both compiler camps..

              Linus