linux-kernel - Re: [PATCH v5 24/28] x86/fpu/xstate: Use per-task xstate mask for saving xstate in signal frame

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: <CAJvTdK=ZRFxh1=e0q7JbtNDfQWrS1d3TzrMHGiTg2Eaq1LsRSw@mail.gmail.com>
Date:   Mon, 24 May 2021 14:06:37 -0400
From:   Len Brown <lenb@...nel.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     "Chang S. Bae" <chang.seok.bae@...el.com>,
        Borislav Petkov <bp@...e.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, X86 ML <x86@...nel.org>,
        "Brown, Len" <len.brown@...el.com>,
        Dave Hansen <dave.hansen@...el.com>,
        "Liu, Jing2" <jing2.liu@...el.com>,
        "Ravi V. Shankar" <ravi.v.shankar@...el.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 24/28] x86/fpu/xstate: Use per-task xstate mask for
 saving xstate in signal frame

On Sun, May 23, 2021 at 11:15 PM Andy Lutomirski <luto@...nel.org> wrote:
>
> If I'm reading this right, it means that tasks that have ever used AMX
> get one format and tasks that haven't get another one.

No.  The format of the XSTATE on the signal stack is uncompressed XSAVE
format for both AMX and non-AMX tasks, both before and after this patch.
That is because XSAVE gets the format from XCR0.  It gets the fields
to write from the run-time parameter.

So the change here allows a non-AMX task to skip writing data (zeros)
to the AMX region of its XSTATE buffer.

The subsequent patch adds the further optimization of (manually) checking
for INIT state for an AMX-task and also skip writing data (zeros) in that case.

We should have done this optimization for AVX-512, but instead we
guaranteed writing zeros, which I think is a waste of both transfer time
and cache footprint.

Len Brown, Intel Open Source Technology Center