Messages in this thread | | | Date | Tue, 28 Oct 2014 20:48:23 +0100 | Subject | Re: [PATCHv2 1/3] x86, ptdump: Add section for EFI runtime services | From | Mathias Krause <> |
| |
On 28 October 2014 19:57, Borislav Petkov <bp@alien8.de> wrote: > [...] > > Ok, thanks for refreshing this for me, your patch is good, so > > Acked-by: Borislav Petkov <bp@suse.de>
Thanks. But as you said, the EFI mappings shouldn't be in the kernel's page table in the first place, so I'd rather see a patch doing that instead. But, in the meantime, this patch is valid, as it shows the "status quo".
> What this whole story shows, however, is that the EFI mappings are in > fact in the kernel page table and this shouldn't be IMO - I'd like to > very much have them split because otherwise there's no need to switch > page tables at all.
Indeed.
> And besides, having UEFI in its own address space is > a good thing in itself anyway. > > So, I've already hacked up something to have a completely separate EFI > page table - need to find out why it doesn't work yet
I tried so too but failed early as well. I tried putting the EFI virtual mappings not in trampoline_pgd[511] but trampoline_pgd[510]. However, that didn't work out. I got page faults when trying to invoke EFI functions, as, apparently, efi.systab was only mapped in the EFI page table but not the kernel's page table -- at least not at the same address. So when efi_call_virt() tries to dereference efi.systab->runtime->f, it just traps. I tried to hack around that by fiddling with get_systab_virt_addr() to make it point to the direct mapping for the phys_addr but failed on the first few attempts to get the math right. Then I noticed it was way to late to hack EFI code and fell asleep. Next day I just gave up and 'git reset --hard HEAD'. :(
> but qemu was > b0rked until recently so we had to deal with that first... bla bla.
Debian's version of qemu + OVMF works fine here. Probably slightly outdated but still good enough for testing EFI stuff ;)
Regards, Mathias
| |