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

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <537A8A03.8060604@zytor.com>
Date:	Mon, 19 May 2014 15:47:31 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Matt Fleming <matt@...sole-pimps.org>,
	Ingo Molnar <mingo@...nel.org>
CC:	linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
	Borislav Petkov <bp@...en8.de>,
	"Luck, Tony" <tony.luck@...el.com>
Subject: Re: [GIT PULL] EFI changes for v3.16

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/