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-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html