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:49:36 +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 22:26, Borislav Petkov <bp@...en8.de> wrote:
> On Tue, Oct 28, 2014 at 10:14:25PM +0100, Mathias Krause wrote:
>> Oh, well. Have fun with that! I would take the "map kernel into EFI
>> page table" route instead. ;)
>
> Actually, I want to try to keep them completely separate and sync only
> before an EFI RT call for function arguments.

Sync only data or kernel code, too?

> And then remove PGDs after
> I return from it. We'll see how it all works out.

That shouldn't be needed as you're switching away from the EFI page
table, so its entries wouldn't be effective any more anyway.

Really, I'd just map the EFI RT service virtual mappings "somewhere"
but at pgd[511] and have pgd[511] initially set up as
init_level4_pgt[511]. Then, thing should "just work"(TM).

If you fear the EFI code might do harm to the kernel code/data, then
you've lost anyway. Nothing will prevent the EFI code from doing nasty
things -- like setting up its own mappings to tamper with the kernel's
memory.

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/