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

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <53909E1B.3020503@zytor.com>
Date:	Thu, 05 Jun 2014 09:43:07 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Andy Lutomirski <luto@...capital.net>
CC:	Borislav Petkov <bp@...en8.de>,
	Matt Fleming <matt.fleming@...el.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>,
	"linux-tip-commits@...r.kernel.org" 
	<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:x86/efi] x86/efi: Check for unsafe dealing with FPU state
 in irq ctxt

On 06/05/2014 09:35 AM, Andy Lutomirski wrote:
>>
>> 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.
> 

I strongly suspect we also want to make sure that we don't ever let more
than one CPU into EFI context.  This would also make it possible to have
a dedicated XSAVE buffer for EFI.

Now, the tricky part: what do we do if another CPU is already in EFI and
we want to do something.

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

No, enabling SSE for all kernel code would force us to context-switch on
any kernel entry or exit, which is way too expensive for what it gains.
 However, perhaps the realtime people will be happier if we don't have
to stop preemption.

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