linux-kernel - Re: math_state_restore and kernel_fpu

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: <alpine.DEB.2.10.1401281215060.5828@minerva.lan>
Date:	Tue, 28 Jan 2014 12:23:20 -0700 (MST)
From:	Nate Eldredge <nate@...tsmathematics.com>
To:	George Spelvin <linux@...izon.com>
cc:	adilger@...ger.ca, arjan@...ux.intel.com, jack@...e.cz,
	linux-kernel@...r.kernel.org, maarten-baert@...mail.com,
	mingo@...e.hu, suresh.b.siddha@...el.com, tglx@...utronix.de,
	viro@...iv.linux.org.uk
Subject: Re: math_state_restore and kernel_fpu_end disable interrupts?

On Tue, 28 Jan 2014, George Spelvin wrote:

>> I'm trying it now.  But it takes a while for me to reproduce, and even
>> longer to be sure the problem has gone away.  So anything you hear from
>> me within a week will be bad news.
>
> Well, it's been a week, and: good news!
>
> I'd still wish for some review by someone who really understands this
> code; in particular it seems dangerous to just enable interrupts for
> a window without re-checking the condition afterward.

Yeah, I was thinking the same.  If interrupts were disabled on entry it 
was probably for a good reason, and it is strange for math_state_restore() 
and/or kernel_fpu_end() to unilaterally enable them.  Maybe the caller is 
supposed to know this and account for it, but I didn't see any 
documentation of the intended semantics of kernel_fpu_{begin,end}() with 
respect to interrupts.  The current behavior doesn't really make sense 
either way, but it does make me wonder if something deeper is wrong.

> [...]
>
> But this patch clearly doesn't make these issues any *worse*, so
> these concerns are no reason to block it.
>
>
> Would you like add an appropriate commit message and send in the patch?

Ok, when I have a chance I will write something up and send it in, and 
maybe having it as a formal patch submission will get more attention.

Thanks, George!

-- 
Nate Eldredge
nate@...tsmathematics.com

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