linux-kernel - Re: [PATCH] Map in physical addresses in efi_map_region

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, 16 Aug 2016 13:30:28 +0100
From:	Matt Fleming <matt@...eblueprint.co.uk>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Alex Thorlton <athorlton@....com>, linux-kernel@...r.kernel.org,
	Russ Anderson <rja@....com>,
	Dimitri Sivanich <sivanich@....com>,
	Mike Travis <travis@....com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
	linux-efi@...r.kernel.org, Dave Young <dyoung@...hat.com>
Subject: Re: [PATCH] Map in physical addresses in efi_map_region_fixed

On Mon, 15 Aug, at 05:07:09PM, Borislav Petkov wrote:
> On Mon, Aug 15, 2016 at 01:42:58PM +0100, Matt Fleming wrote:
> > (Cc'ing Boris and Dave)
> > 
> > On Fri, 05 Aug, at 06:59:35PM, Alex Thorlton wrote:
> > > This is a simple change to add in the physical mappings as well as the
> > > virtual mappings in efi_map_region_fixed.  The motivation here is to
> > > get access to EFI runtime code that is only available via the 1:1
> > > mappings on a kexec'd kernel.
> 
> So I don't understand: the whole jumping through hoops so that we have
> stable virtual mappings just so that the kexec-ed kernel can call EFI
> runtime, is now useless?!
> 
> What if the physical address is occupied by the kexec kernel?
 
That's impossible, because that would mean we loaded the kexec kernel
over the top of physical pages of EFI services. We still need to be
able to invoke EFI services from kexec - we just can't change their
virtual mappings.

Unless I've misunderstood your question.

> Why do you guys need the physical mapping all of a sudden?
 
This is because of the way that the SGI firmware works and that the
"new" virtual address mappings are usable on SGI+kexec now.

> Your patch is basically rendering all the effort moot and we could've
> saved ourselves all that trouble of doing all that virtual address
> mapping and done the 1:1 thing.
 
No, some Apple platforms will not boot if SetVirtualAddressMap()
passes 1:1 mappings, and we only enter the firmware via the 1:1
mappings for EFI mixed mode calls. We're still using the virtual
runtime mappings in the commit you reference below most of the time.
 
> Which really is probably simpler since we have an EFI-specific page
> table and running EFI in the kexec-ed kernel would mean basically
> recreating it.
> 
> What am I missing?
> 
> commit d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c
> Author: Borislav Petkov <bp@...e.de>
> Date:   Thu Oct 31 17:25:08 2013 +0100
> 
>     x86/efi: Runtime services virtual mapping
>     
>     We map the EFI regions needed for runtime services non-contiguously,
>     with preserved alignment on virtual addresses starting from -4G down
>     for a total max space of 64G. This way, we provide for stable runtime
>     services addresses across kernels so that a kexec'd kernel can still use
>     them.
> 
> -- 
> Regards/Gruss,
>     Boris.
> 
> ECO tip #101: Trim your mails when you reply.
> --