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]

Message-ID: <20160816152513.GT214806@stormcage.americas.sgi.com>
Date:	Tue, 16 Aug 2016 10:25:14 -0500
From:	Alex Thorlton <athorlton@....com>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Alex Thorlton <athorlton@....com>,
	Matt Fleming <matt@...eblueprint.co.uk>,
	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 Tue, Aug 16, 2016 at 07:50:10AM +0200, Borislav Petkov wrote:
> On Mon, Aug 15, 2016 at 01:47:31PM -0500, Alex Thorlton wrote:
> > The only thing we're adding here is the physical mappings, to match
> > what is availble in the primary kernel.
> 
> I can see what it does - I just am questioning the reasoning for as we
> did all that effort so that kexec can have stable virtual mappings.
> 
> I guess we still need a way to pass the virtual mappings to kexec
> as they're immutable as some "smartass" decided to allow to call
> SetVirtualAddressMap only once.
> 
> > This is sort of a hand-wavey answer - I will investigate the his further...
> 
> Yeah, it'll be interesting to know whether that is an issue because if
> we do the 1:1 mappings in the kexec kernel too and there's an address
> conflict, then we better know upfront.

I did some investigation/testing here and found, as Matt stated, that
this shouldn't cause any serious problems.  The crashkernel memory
reservation happens a little later than I originally thought, so we sort
of hit a hybrid of the two problems I described.  i.e, the memory isn't
mapped yet, but the kernel does know not to map anything over it.

I purposely set the crashkernel to land right on top of some of our
MMRs:

#define UV2_GLOBAL_MMR32_BASE           0xfc000000UL

This is 4227858432 in base10, or 4128768K in crashkernel parameter
terms, so I used this on the command line:

crashkernel=256M@...8768K

And, not too surprisingly, I hit this while trying to reserve the
crashkernel memory:

[    0.000000] crashkernel reservation failed - memory is in use.

At a glance, I believe that this is because the memory range for these
MMRs is E820_RESERVED:

[    0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fdffffff] reserved

So, it gets skipped over during memblock_x86_fill, which only picks up
E820_RAM, and E820_RESERVED_KERN memory.  At least in this case, the
memory range where our MMRs fall is seen as completely unavailable (or,
more accurately, not seen at all) when we do the memblock_find_in_range
during reserve_crashkernel.

Note that I chose to map over some MMR space instead of EFI runtime
code.  This was an arbitrary choice - they both show up as
E820_RESERVED, so the behavior will be the same.

This is certainly not news to some, but I wasn't positive about how this
worked, and wanted to make sure that I addressed the concern that you
expressed.

Thanks again for your input!

- Alex