Re: [GIT PULL] EFI changes for v3.16

[H. Peter Anvin]

On 05/19/2014 03:51 AM, Matt Fleming wrote:
> On Sat, 03 May, at 02:04:47PM, Matt Fleming wrote:
>> Folks, please queue the following change for v3.16 from Borislav that
>> uses the more strict kernel_fpu_{begin,end}() instead of the __*
>> verisons that won't catch buggy use in interrupt context.
>>
>> The following changes since commit e33655a386ed3b26ad36fb97a47ebb1c2ca1e928:
>>
>>   efivars: Add compatibility code for compat tasks (2014-04-17 13:53:53 +0100)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git tags/efi-next
>>
>> for you to fetch changes up to baa916f39b50ad91661534652110df40396acda0:
>>
>>   x86/efi: Check for unsafe dealing with FPU state in irq ctxt (2014-05-03 06:39:25 +0100)
>>
>> ----------------------------------------------------------------
>>  * Use the more strict FPU handling functions before invoking EFI
>>    services to catch misuse in irq context - Borislav Petkov
> 
> Ping?
> 

>     efi_call can happen in an irq context (pstore) and there we really need
>     to make sure we're not scribbling over FPU state while we've interrupted
>     a thread or kernel mode with a live FPU state. Therefore, use the
>     kernel_fpu_begin/end() variants which do that check.

How on earth does this solve anything?  The only thing we add here is a
WARN_ON_ONCE()... but the above text already tells us we have a problem.

It seems, rather, that we need to figure out how to deal with a pstore
in this case.  There are a few possibilities:

1. We could keep an XSAVE buffer area around for this particular use.
   I am *assuming* we don't let more than one CPU into EFI, because I
   cannot for my life imagine that this is safe in typical CPUs.

2. Drop the pstore on the floor if !irq_fpu_usable().

3. Allow the pstore, then die (on the assumption that we're dead
   anyway.)

Comments?

	-hpa

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