linux-kernel - Re: [PATCHv2 1/3] x86, ptdump: Add section for EFI runtime services

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]

Date:	Tue, 28 Oct 2014 22:14:25 +0100
From:	Mathias Krause <minipli@...glemail.com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Matt Fleming <matt@...sole-pimps.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	x86-ml <x86@...nel.org>, Matt Fleming <matt.fleming@...el.com>
Subject: Re: [PATCHv2 1/3] x86, ptdump: Add section for EFI runtime services

On 28 October 2014 21:13, Borislav Petkov <bp@...en8.de> wrote:
> On Tue, Oct 28, 2014 at 08:48:23PM +0100, Mathias Krause wrote:
>> 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'. :(
>
> I know exactly what you mean. The nasty thing about it is, debugging
> this is not trivial as once you switch to another page table, you don't
> have a #PF handler and the guest triple-faults. All of the above issues
> I've encountered already while hacking on the current code :-) *Cringe*

Mapping the kernel into the EFI page table may help ;) Then the
kernel's #PF handler would be present and able to print a register
dump, at least.

So, assuming you're not mapping the EFI virtual mappings below the
pgd[511] hierarchy, making pgd[511] equal init_level4_pgt[511] should
help in this case. In fact, you need to map portions of the kernel
into the EFI page table anyway. Otherwise the EFI code wouldn't be
able to access, e.g., the data it should write to NVRAM. So the EFI
code would just trap and trigger a #PF -- and because of the missing
#PF handler, a #DF -- and because of the missing #DF handler the
triple fault. ;)

>
> I want to do experimentation with tracing page faults in KVM with the
> nested PF handling in hw turned off so that I can see all #PFs. Maybe
> that'll tell me something more, we'll see.

Oh, well. Have fun with that! I would take the "map kernel into EFI
page table" route instead. ;)

>
>> Debian's version of qemu + OVMF works fine here. Probably slightly
>> outdated but still good enough for testing EFI stuff ;)
>
> Yeah, Paolo fixed it already:
>
> https://lkml.kernel.org/r/1414420306-2771-2-git-send-email-pbonzini@redhat.com
>
> I think we want to keep qemu+kvm functioning :-)

Of course! It makes testing a lot easier.


Cheers,
Mathias
--
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/