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]

Message-ID: <CA+rthh9qePkJogFDT+ttSLvYPvJrAM6CXMJ407Hq3PjcRw9WTw@mail.gmail.com>
Date:	Tue, 28 Oct 2014 20:48:23 +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 19:57, Borislav Petkov <bp@...en8.de> wrote:
> [...]
>
> Ok, thanks for refreshing this for me, your patch is good, so
>
> Acked-by: Borislav Petkov <bp@...e.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
--
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/