linux-kernel - Re: [PATCH 09/11] x86, fpu: correct and check XSAVE xstate size calculations

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: <87oahr1hy6.fsf@tassilo.jf.intel.com>
Date:	Fri, 28 Aug 2015 09:44:17 -0700
From:	Andi Kleen <andi@...stfloor.org>
To:	Dave Hansen <dave@...1.net>
Cc:	Ingo Molnar <mingo@...nel.org>, dave.hansen@...ux.intel.com,
	bp@...en8.de, fenghua.yu@...el.com, hpa@...or.com, x86@...nel.org,
	tim.c.chen@...ux.intel.com, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Kleen\, Andi" <andi.kleen@...el.com>,
	alexander.shishkin@...ux.intel.com, peterz@...radead.org
Subject: Re: [PATCH 09/11] x86, fpu: correct and check XSAVE xstate size calculations

Dave Hansen <dave@...1.net> writes:

>> 
>> That would give us a gentle way to double check our assumptions here.
>
> Actually, the newest state that you will see in the wild is for
> Processor Trace, and it _is_ a supervisor state.  However, we don't use
> it in Linux for our Processor Trace support, and Andi says we probably
> never will.
>
> So we probably shouldn't warn on it.

Yes we shouldn't. It would be unnecessary scary for people with old
kernels on newer hardware. Since supervisor state needs generally a
driver, it's harmless to ignore if there is none.

As to why Processor Trace is not using it:

The XSAVE support assumes that there is a single buffer for each
thread. But perf generally doesn't work this way, it usually has
only a single perf event per CPU per user, and when tracing
multiple threads on that CPU it inherits perf event buffers between
different threads. So XSAVE per thread cannot handle this inheritance
case directly.

Using multiple XSAVE areas (another one per perf event) would defeat
some of the state caching that the CPUs do.

In theory it would be possible to detect when inheritance is not used
and only use XSAVE in this case. But it's not clear that is common
enough and worth the trouble.

For now the manual MSR based switching seems to work well enough,
although it's more overhead.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only
--
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/