linux-kernel - Re: [RFC 2/2] x86, xsave: rework xsave support

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:	Wed, 24 Nov 2010 19:36:34 -0500
From:	Brian Gerst <brgerst@...il.com>
To:	Hans Rosenfeld <hans.rosenfeld@....com>
Cc:	linux-kernel@...r.kernel.org, x86@...nel.org,
	robert.richter@....com, andreas.herrmann3@....com
Subject: Re: [RFC 2/2] x86, xsave: rework xsave support

On Tue, Nov 23, 2010 at 3:41 PM, Hans Rosenfeld <hans.rosenfeld@....com> wrote:
> This is an attempt to rework the code that handles FPU and related
> extended states. Since FPU, XMM and YMM states are just variants of what
> xsave handles, all of the old FPU-specific state handling code will be
> hidden behind a set of functions that resemble xsave and xrstor. For
> hardware that does not support xsave, the code falls back to
> fxsave/fxrstor or even fsave/frstor.
>
> A xstate_mask member will be added to the thread_info structure that
> will control which states are to be saved by xsave. It is set to include
> all "lazy" states (that is, all states currently supported) by the #NM
> handler when a lazy restore is triggered or by switch_to() when the
> tasks FPU context is preloaded. Xstate_mask is intended to completely
> replace TS_USEDFPU in a later cleanup patch.
>
> When "non-lazy" states such as for LWP will be added later, the
> corresponding bits in xstate_mask are supposed to be set for all threads
> all the time. There will be no performance penalty for threads not using
> these states, as xsave and xrstor will ignore unused states.
>
> This patch is not complete and not final at all. Support for 32bit is
> lacking, and the context handling for signals will probably change
> again. I haven't benchmarked it yet, but I have tested it for both the
> fxsave and xsave cases.

Looks good, but I would suggest adding wrappers for save_states() and
restore_xstates() that handle preemption, like how unlazy_fpu() was.

--
Brian Gerst
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/