linux-kernel - Re: [PATCH, 3.18] sleeping function called from invalid context

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: <CALCETrV5jH6GJb=WVqMe7M1=JFPOWKm5r3QRkmF0jBy4joCyYA@mail.gmail.com>
Date:	Wed, 10 Dec 2014 17:53:44 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Rik van Riel <riel@...hat.com>
Cc:	Daniel J Blueman <daniel@...ra.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH, 3.18] sleeping function called from invalid context

On Wed, Dec 10, 2014 at 5:32 PM, Rik van Riel <riel@...hat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 12/10/2014 07:51 PM, Andy Lutomirski wrote:
>> On Wed, Dec 10, 2014 at 4:49 PM, Rik van Riel <riel@...hat.com>
>> wrote: On 12/10/2014 07:46 PM, Daniel J Blueman wrote:
>>>>> Gah. I had some non-temporal copy changes in the wrong tree.
>>>>> I'll check with a definitely clean tree and follow up if it
>>>>> still occurs.
>>
>> The exception handlers should definitely allow sleeping, so I
>> suspect those changes may be related.
>>
>>> It would be really, really nice if we could arrange for
>>> kernel_fpu_begin to be unconditionally usable in anything except
>>> NMI context.  The crypto code would be much less scary, we could
>>> make non-temporal copies safe, etc.  Can we have ponies, too?
>
> Isn't it already?
>
> I see nothing in __kernel_fpu_begin that looks like it would
> ever need to sleep.
>

It never needs to sleep, but it does need somewhere to save the
previous state.  See irq_fpu_usable.

FWIW, I don't understand what the comments above
interrupted_kernel_fpu_idle are talking about.  The issue that I
understand is:

kernel_fpu_begin()

irq:
  kernel_fpu_begin()
  use xstate
  kernel_fpu_end()

we're screwed now :(

kernel_fpu_end()

IOW we need somewhere to put the state from the thing we interrupted.
This gets extra fun if some thread does something that takes a page
fault that uses fpu that gets interrupted, etc.  Fortunately, I think
that can't happen -- kernel_fpu_begin disables preemption.  So I think
we have a maximum of one active FPU context per thread plus some
number per cpu.  Maybe we could have a percpu array of ten or twenty
xstates to handle all possible nesting.

Also, can we just delete the non-eager code some day?

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