Re: Curious crash with secure variables

["H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>]

On 03/18/2013 11:04 AM, Matt Fleming wrote:
> On 03/18/2013 03:32 PM, David Woodhouse wrote:
>> On Mon, 2013-03-18 at 15:16 +0000, Matt Fleming wrote:
>>>
>>> See,
>>>
>>>   commit 53b87cf0 ("x86, mm: Include the entire kernel memory map in trampoline_pgd"),
>>>   commit 185034e7 ("x86, efi: 1:1 pagetable mapping for virtual EFI calls"),
>>>   commit da5a108d05b4 ("x86/kernel: remove tboot 1:1 page table creation code") and 
>>>   commit bd52276fa1d4 ("x86-64/efi: Use EFI to deal with platform wall clock (again)")
>>>
>>>  and the two revert commits from Linus, be354f40 and 11520e5e.
>>
>> Thanks. That seems like a rather scary approach. I was thinking of just
>> setting up a dedicated kernel thread for making runtime services calls,
>> and giving it some "userspace" page tables with a 1:1 mapping. No
>> messing around with %cr3 directly.
> 
> How would that work? Would it be a real, executable thread context as
> opposed to just an address space? In which case would we be passing data
> to this thread for it to execute on our behalf? One thing to be aware of
> is that sometimes we need to make EFI calls when the sky is falling,
> such as writing EFI variables in the pstore code paths when crashing.
> Scheduling things at that point may be difficult.
> 
> Provided that you can still do things like that, it seems like a nice
> solution.
> 

What is the point?

We don't need the scheduler to be involved, we just want to do a
temporary context switch.  We can't preempt EFI anyway, so given that,
we are non-preemptable and switching %cr3 is fine.

	-hpa