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

From: Andy Lutomirski
Date: Thu Jun 05 2014 - 12:15:21 EST


On Thu, Jun 5, 2014 at 9:08 AM, Borislav Petkov <bp@xxxxxxxxx> wrote:
> On Thu, Jun 05, 2014 at 09:01:02AM -0700, Andy Lutomirski wrote:
>> NMI might be okay. I haven't checked.
>
> Well, if efi decides to do FPU math and it happens in NMI, we will have
> to provide for proper contexts handling.
>
>> It has to change back, though. Completely unrealistic and useless example:
>>
>> int ctxt = what_context_im_in();
>>
>> set_up_the_fpu(ctxt);
>>
>> // kprobe fires and changes the context
>> // kprobe does something
>
> And since we're being completely unrealistic, kprobe decides to use the
> fpu too and uses it...

Sure. So it either needs to save and restore the state or to save it
and mark it for restore when the kprobe entry context is torn down.

>
>> // kprobe changes the context back
>>
>> use the FPU. Life is good.
>>
>> put_back_the_fpu(ctxt);
>
> So you probably need some way of mapping preallocated, per-cpu FPU
> contexts to their users which can get and put them.
>
> It's a whole different question whether that makes sense though, at all
> or we simply remain conservative and don't do any efi in NMI context...

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 :)

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.

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