linux-kernel - Re: question about save_xstate_sig()

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: <54C7FA09.4000908@redhat.com>
Date:	Tue, 27 Jan 2015 15:50:17 -0500
From:	Rik van Riel <riel@...hat.com>
To:	Oleg Nesterov <oleg@...hat.com>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Andy Lutomirski <luto@...capital.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Fenghua Yu <fenghua.yu@...el.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: question about save_xstate_sig() - WHY DOES THIS WORK?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/27/2015 03:27 PM, Rik van Riel wrote:
> On 01/27/2015 02:40 PM, Oleg Nesterov wrote:

>>>> - Why unlazy_fpu() always does __save_init_fpu() even if 
>>>> use_eager_fpu?
>>>> 
>>>> and note that in this case __thread_fpu_end() is wrong if 
>>>> use_eager_fpu, but fortunately the only possible caller of 
>>>> unlazy_fpu() is coredump. fpu_copy() checks use_eager_fpu().
>>>> 
>>>> - Is unlazy_fpu()->__save_init_fpu() safe wrt 
>>>> __kernel_fpu_begin() from irq?
> 
> It looks like it should be safe, as long as __save_init_fpu() knows
> that the task no longer has the FPU after __kernel_fpu_end(), so it
> does not try to save the kernel FPU state to the user's 
> task->thread.fpu.state->xstate
> 
> The caveat here is that __kernel_fpu_begin()/__kernel_fpu_end() 
> needs to be kept from running during unlazy_fpu().
> 
> This means interrupted_kernel_fpu_idle and/or irq_fpu_usable need
> to check whether preemption is disabled, and lock out 
> __kernel_fpu_begin() when preemption is disabled.
> 
> It does not look like it currently does that...

... and that won't work, because preempt_disable() is a noop
without CONFIG_PREEMPT enabled. Sigh.

Not sure how to work around that, except by having
__Kernel_fpu_end() always restore the task FPU state, if the
task had the FPU when entering.

This suggests it may be advantageous to be liberal with
__thread_fpu_end() when we know user space will not be touching
the FPU again for a while, since that would reduce the work
done by __kernel_fpu_begin()/__kernel_fpu_end().

Does that make sense?

- -- 
All rights reversed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUx/oJAAoJEM553pKExN6Dh4YH/AtVOza5VeZuz55s59LifpLt
5eXMQBxQt0JiX9NACc+7qXDuEFfkmnzhNpNT98abuic7/1dvj2TfcoXSnkysDaNb
WojFW0gMc973G4UA6ZPsqScxz7jdfaqNrFdFEaTPM6URClIllVXTgnCcDoWCFfR2
627s6vyOW//BgXnedHraGGqnBVpCBLWrsVnhJ0RbPd2cjrrwKPXcbLnk6+uzZqLY
/7Zp2fSDjuAY6PhxRZM529vyJNqIM2mhlKFG8/xnch95mlXwtOQvLuuJmkwbKabb
6Z1gqpyEXbWyB2riD/pQrIlkOg2P4UuLONM7fgFY4Dzc8MEM7UmNR4mWoPAeBuU=
=SSqD
-----END PGP SIGNATURE-----
--
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/