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: <20150116160308.GB7249@redhat.com>
Date:	Fri, 16 Jan 2015 17:03:08 +0100
From:	Oleg Nesterov <oleg@...hat.com>
To:	Rik van Riel <riel@...hat.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Suresh Siddha <sbsiddha@...il.com>,
	linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
	matt.fleming@...el.com, bp@...e.de, pbonzini@...hat.com,
	tglx@...utronix.de, luto@...capital.net
Subject: Re: [PATCH 3/3] x86, fpu: fix math_state_restore() race with
	kernel_fpu_begin()

On 01/15, Rik van Riel wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/15/2015 02:20 PM, Oleg Nesterov wrote:
> > math_state_restore() can race with kernel_fpu_begin() if irq comes
> > right after __thread_fpu_begin(), __save_init_fpu() will overwrite
> > fpu->state we are going to restore.
> >
> > Add 2 simple helpers, kernel_fpu_disable() and kernel_fpu_enable()
> > which simply set/clear in_kernel_fpu, and change
> > math_state_restore() to exclude kernel_fpu_begin() in between.
> >
> > Alternatively we could use local_irq_save/restore, but probably
> > these new helpers can have more users.
> >
> > Perhaps they should disable/enable preemption themselves, in this
> > case we can remove preempt_disable() in __restore_xstate_sig().
>
> Given that math_state_restore does an implicit preempt_disable
> through local_irq_disable,

Not really. do_device_not_available() calls it with irqs disabled,
__restore_xstate_sig() calls it under preempt_disable().

> I am not sure whether adding an
> explicit preempt_disable would be good or bad.

Me too, but this code needs cleanups in any case imo, lets do this
later.

> Reviewed-by: Rik van Riel <riel@...hat.com>

Thanks!


I'll try to send another short series today, we need to remove
__thread_has_fpu() from interrupted_kernel_fpu_idle() before we
add TIF_LOAD_FPU.

Oleg.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ