linux-kernel - Re: [RFC PATCH 04/11] x86,fpu: defer FPU restore until return to userspace

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:	Tue, 13 Jan 2015 09:18:22 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Rik van Riel <riel@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Matt Fleming <matt.fleming@...el.com>,
	Borislav Petkov <bp@...e.de>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH 04/11] x86,fpu: defer FPU restore until return to userspace

On Tue, Jan 13, 2015 at 9:11 AM, Oleg Nesterov <oleg@...hat.com> wrote:
> On 01/11, riel@...hat.com wrote:
>>
>> Defer restoring the FPU state, if so desired, until the task returns to
>> userspace.
>
> And I have another concern.
>
> Afaocs with this patch the idle threads will run with TIF_LOAD_FPU set but
> without fpu.has_fpu.

Yuck.  IMO there are still too many possible states.

AFAICS the sensible states for a task are:

 - Task is current on some cpu and FPU is loaded into that cpu.
 - Task is current on some cpu and FPU is in memory.
 - Task is current on some cpu and FPU is loaded into a different cpu.
 - Task is not current and FPU is in memory.
 - Task is not current and FPU is loaded into some cpu.

Am I missing anything?  (In lazy mode, there are a few more involving CR0.TS.)

That's five states, plus an optional cpu number.  But we have tons of
state variable that can express all kinds of nonsense things.

If we asserted that we were in a sensible state and fixed the things
that exited the sensible states, maybe this would be easier to
understand and debug.

--Andy
--
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/