linux-kernel - Re: [RFC PATCH] Fix EFI callbacks on UV during kexec

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: <20160801133926.GG3636@codeblueprint.co.uk>
Date:	Mon, 1 Aug 2016 14:39:26 +0100
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	Alex Thorlton <athorlton@....com>
Cc:	linux-kernel@...r.kernel.org, Russ Anderson <rja@....com>,
	Mike Travis <travis@....com>, Borislav Petkov <bp@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org
Subject: Re: [RFC PATCH] Fix EFI callbacks on UV during kexec

On Tue, 26 Jul, at 05:38:32PM, Alex Thorlton wrote:
> 
> After investigating the problem here and figuring out the proper way to
> get the noefi parameter working again, I noticed that there appears to
> be support for EFI runtime callbacks in a kexec'd kernel now...  I
> think we need some more cleanup here to get that all working entirely.
> Without noefi, we hit a bad paging request when we try to do EFI 
> callbacks:
 
[...]

> [    0.341531] BUG: unable to handle kernel paging request at 000000006a1ab938
> [    0.349319] IP: [<000000006a1ab938>] 0x6a1ab938
> [    0.354386] PGD 354e0063 PUD 0
> [    0.357910] Oops: 0010 [#1] SMP
> [    0.361414] Modules linked in:
> [    0.364833] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.7.0-runtime-check+ #713

[...]

> This is due to the fact that the efi_map_region_fixed calls in
> kexec_enter_virtual_mode, which map in the EFI runtime memory
> descriptors, only map the virtual address of the descriptor.
> Unfortunately, since we're still relying on the physical address of our
> EFI runtime code being mapped in, we don't have access to that code in
> the kexec scenario.
> 
> A potential fix for this would be to map in the physical addresses of
> the descriptors as well as the virtual addresses in
> efi_map_region_fixed, but the more "correct" fix would be to update
> our system table pointer to its new virtual address during
> SetVirtualAddressMap.  We intend to get that piece fixed up relatively
> soon, but haven't quite gotten around to it yet.

I don't think it would be so bad if we did the 1:1 mappings in the
kexec kernel too, we've got our own page tables after all and the VA
space is available. It would be required if people ever want to use
kexec with mixed mode kernels too.