Re: [tip:x86/efi] x86/efi: Check for unsafe dealing with FPU state in irq ctxt

[Andy Lutomirski]

On Thu, Jun 5, 2014 at 9:31 AM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> On 06/05/2014 09:18 AM, Borislav Petkov wrote:
>> On Thu, Jun 05, 2014 at 09:14:51AM -0700, Andy Lutomirski wrote:
>>> Is this NMI pstore thing done from any context that's supposed to be
>>> recoverable? It's always safe to use the FPU and then panic :)
>>
>> Right :)
>>
>>> Anyway, if we're just talking about EFI, there's an easier solution:
>>> just preallocate a per-cpu FPU context for EFI and make the whole mess
>>> be local to the EFI code.  For crypto, that's not so good.
>>
>> This is probably something for Matt to decide but it sounds doable. If
>> I'd have to guess, sooner or later we will need to do proper FPU context
>> handling for EFI as I don't see anything stopping it from using FPU
>> insns. At least we won't. :-)
>>
>
> The bottom line is that we can't call EFI from a context where we can't
> use the FPU.  Or specifically, we can't then resume execution.  If all
> we're doing is stashing away some data before dying, well, then, by all
> means - but we need to make sure that is what actually happens.

I bet we have to be extra careful about EFI: I imagine that, if we
take an NMI or MCE while in EFI code, another call into EFI is a
terrible idea, which might be a good reason to have the EFI code track
its own context and prevent nesting.

>
> As far adding additional xstate save areas, the current size of the
> xstate is about ~2.5K for AVX-512 enabled processors, and we need one
> per thread.  If we make that two copies, then
> kernel_fpu_begin()..._end() would no longer have to disable preemption,
> but it wouldn't resolve the conflict about using the FPU from IRQ
> context when inside kernel_fpu_begin().._end().
>
> To support the FPU in IRQ context we end up having to create a percpu
> FPU state stack, and it becomes then a matter of how deep that stack
> would have to be.

I suppose it's a question of how valuable making a change like this
would be (two per-thread xstate areas plus a bunch per cpu, say).  I
doubt that the memory usage matters much, but writing and maintaining
it will be a mild PITA.  Maybe no worse than the current stuff.

What are the major users?  If it worked really well, we could enable
SSE for all kernel code, but at least all the crypto stuff would
benefit a lot.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/