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+rthh_t7gw=+j5M91hGv29py7JpH7Whffjakp4YS5zS1i15jw@mail.gmail.com>
Date:	Wed, 29 Oct 2014 09:06:55 +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 23:07, Borislav Petkov <bp@...en8.de> wrote:
> On Tue, Oct 28, 2014 at 10:49:36PM +0100, Mathias Krause wrote:
>> Sync only data or kernel code, too?
>
> Data only should be enough.

No, not really. This is why:

1/ When setting up the virtual mapping via a call to the
SetVirtualAddressMap EFI service we're running with interrupts
enabled, as we skip to disable them in efi_call_phys_prolog(). This
means, IRQs might happen and, in fact, they *do* happen. I know for
sure, because I had to debug an issue with a "wbinvd" instruction
within that EFI code delaying execution long enough, that the timer
interrupt triggers. So we should be prepared to handle those by having
the kernel mapped during the EFI call or bad things will happen.
2/ When the EFI code traps, e.g., because the EFI code is buggy or the
arguments the kernel provides are borked, not having a trap handler
for #PF, #GP, #UD, you name it, will make the system just triple fault
and reset. From a user perspective, that's not nice. ;)

So, having the kernel mapped during EFI calls is kinda required. I
rather prefer seeing the system panic with a backtrace instead of just
triple faulting.

>> 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).
>
> Nah, nothing with EFI just works :-)

Yeah, learned it the hard way, too ;)

>
>> 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.
>
> Sure, nothing would surprise me anymore. However, I'd prefer to not be
> an enabler. :)

We have the EFI code 'n data mapped RWX into the kernel address space
at predictable addresses, now. It can't get any worse ;)

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/