linux-kernel - Re: Why does glibc use AVX-512?

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: <C624A1B5-45EE-491C-B43B-5605D48273E9@amacapital.net>
Date:   Fri, 26 Mar 2021 14:21:05 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Florian Weimer <fw@...eb.enyo.de>
Cc:     Andy Lutomirski <luto@...nel.org>,
        "H. J. Lu" <hjl.tools@...il.com>, X86 ML <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        "Bae, Chang Seok" <chang.seok.bae@...el.com>,
        Carlos O'Donell <carlos@...hat.com>,
        Rich Felker <dalias@...c.org>,
        libc-alpha <libc-alpha@...rceware.org>
Subject: Re: Why does glibc use AVX-512?



> On Mar 26, 2021, at 2:11 PM, Florian Weimer <fw@...eb.enyo.de> wrote:
> 
> * Andy Lutomirski:
> 
>>> On Fri, Mar 26, 2021 at 1:35 PM Florian Weimer <fw@...eb.enyo.de> wrote:
>>> 
>>> I mean the immense slowdown you get if you use %xmm registers after
> their %ymm counterparts (doesn't have to be %zmm, that issue is
> present starting with AVX) and you have not issued VZEROALL or
> VZEROUPPER between the two uses.

It turns out that it’s not necessary to access the registers in question to trigger this behavior. You just need to make the CPU think it should penalize you. For example, LDMXCSR appears to be a legacy SSE insn for this purpose, and VLDMXCSR is an AVX insn for this purpose. I wouldn’t trust that using ymm9 would avoid the penalty just because common sense says it should.

>> What kind of system has that problem?
> 
> It's a standard laptop after a suspend/resume cycle.  It's either a
> kernel or firmware bug.

What kernel version?  I think fixing the kernel makes more sense than fixing glibc.