Re: Curious crash with secure variables

[Matt Fleming <matt-HNK1S37rvNbeXh+fF434Mdi2O/JbrIOy@public.gmane.org>]

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.

-- 
Matt Fleming, Intel Open Source Technology Center