linux-kernel - Re: [RFC PATCH 13/22] x86/fpu/xstate: Expand dynamic user state area on first use

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]

Date:   Tue, 3 Nov 2020 21:53:22 +0000
From:   "Bae, Chang Seok" <chang.seok.bae@...el.com>
To:     "Lutomirski, Andy" <luto@...capital.net>,
        "Hansen, Dave" <dave.hansen@...el.com>
CC:     "mingo@...nel.org" <mingo@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "bp@...e.de" <bp@...e.de>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Liu, Jing2" <jing2.liu@...el.com>,
        "x86@...nel.org" <x86@...nel.org>,
        "luto@...nel.org" <luto@...nel.org>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        "Brown, Len" <len.brown@...el.com>
Subject: Re: [RFC PATCH 13/22] x86/fpu/xstate: Expand dynamic user state area
 on first use

On Tue, 2020-11-03 at 13:41 -0800, Dave Hansen wrote:
> On 11/3/20 1:32 PM, Bae, Chang Seok wrote:
> > On Wed, 2020-10-14 at 09:29 -0700, Dave Hansen wrote:
> > > On 10/14/20 9:10 AM, Andy Lutomirski wrote:
> > > > I was suggesting something a little bit different.  We'd keep XMM,
> > > > YMM, ZMM, etc state stored exactly the way we do now and, for
> > > > AMX-using tasks, we would save the AMX state in an entirely
> > > > separate
> > > > buffer.  This way the pain of having a variable xstate layout is
> > > > confined just to AMX tasks.
> > > 
> > > OK, got it.
> > > 
> > > So, we'd either need a second set of XSAVE/XRSTORs, or "manual"
> > > copying
> > > of the registers out to memory.  We can preserve the modified
> > > optimization if we're careful about ordering, but only for *ONE* of
> > > the
> > > XSAVE buffers (if we use two).
> > 
> > For what is worth,
> > 
> > If using two buffers, the buffer for saving the tile data also needs
> > space
> > for the legacy states.
> 
> Just to be clear, you're talking about the 512-byte 'struct
> fxregs_state' which is the first member of 'struct xregs_state', right?

Yes.

> 
> > The AMX state is stored at the end of the XSAVE buffer (at least for
> > now).
> > So, the layout (in terms of offsets of non-AMX states) won't be changed
> > at
> > run-time.
> 
> I don't know what point you are trying to make here.

I was trying to clarify the concern that Andy had:

	"the pain of having a variable xstate layout"

Thanks,
Chang