linux-kernel - Re: [PATCH v1] x86/fpu: Remove opmask state from avx512

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]

Date:   Thu, 14 Oct 2021 10:49:25 -0500
From:   Noah Goldstein <goldstein.w.n@...il.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     tglx@...utronix.de, mingo@...hat.com, X86 ML <x86@...nel.org>,
        hpa@...or.com, Andy Lutomirski <luto@...nel.org>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] x86/fpu: Remove opmask state from avx512_timestamp check

On Thu, Oct 14, 2021 at 3:28 AM Borislav Petkov <bp@...en8.de> wrote:
>
> On Wed, Oct 13, 2021 at 05:36:14PM -0500, Noah Goldstein wrote:
> > Ping2
>
> Why?

This left me confused and annoyed for several hours because
the avx512 usage information on my applications didn't make
sense. Figured worth a patch for posterity.

>
> The original patch which added this abomination:
>
> 2f7726f95557 ("x86/fpu: Track AVX-512 usage of tasks")
>
> says already:
>
>  the tracking mechanism is imprecise and can theoretically miss AVX-512
>  usage during context switch. But it has been measured to be precise
>  enough to be useful under real-world workloads like tensorflow and
>  linpack.
>
>  If higher precision is required, suggest user space tools to use the
>  PMU-based mechanisms in combination.

This patch isn't about higher precision / false negatives.
It's about false positives.

>
> and as you've noticed, the high 16 regs would cause a false positive
> too.
>
> So what is the actual real-life use case for this?

No big project. There is a case for avoiding the extended avx512
registers (reg16..31) for various reasons (context switches,
code size, instruction limitations) that don't apply to mask registers.

Irrelevant of the still existing flaws, it makes the output more accurate.

Is there a cost to the change I am not seeing?

If not it seems to be a tradeoff between more accurate vs less accurate.
So why not take the former?

>
> --
> Regards/Gruss,
>     Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette