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:	Wed, 17 Aug 2016 11:00:31 -0500
From:	Alex Thorlton <athorlton@....com>
To:	Dave Young <dyoung@...hat.com>
Cc:	Alex Thorlton <athorlton@....com>, Borislav Petkov <bp@...en8.de>,
	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
Subject: Re: [PATCH] Map in physical addresses in efi_map_region_fixed

On Wed, Aug 17, 2016 at 03:01:51PM +0800, Dave Young wrote:
> > > Why do you guys need the physical mapping all of a sudden?
> > 
> > It's not that we need it all of the sudden, necessarily, it's just that
> > we've had to make other changes to make things work with the new,
> > (almost) completely isolated, EFI page tables.  We ended up choosing the
> > lesser of two evils, and have decided to temporarily rely on the
> > physical address of our runtime code, instead of continuing to rely on
> > EFI_OLD_MEMMAP.
> 
> In efi_map_region, there is already mapped md->phys_addr for broken
> firmware. SGI still need EFI_OLD_MEMMAP? I means in 1st kernel instead
> of kexec kernel.

We're actually in the middle of trying to move *away* from
EFI_OLD_MEMMAP, which is why we're just starting to uncover some of
these things.  efi_map_region covers us on the primary kernel, because
it maps in the physical address of each md (as you note here), but that
little piece is missing in the kexec'd kernel.  So, our primary kernel
works without efi=old_map, but the second kernel won't, without this
change (supplying "noefi" on the kexec command line also works, but then
we don't have any of our runtime stuff available).

As noted in a previous message, we're aware that our code needs a little
more work to be "perfect," but this small change buys us most of (all
of?) the stuff we'd get by implementing the other changes that we're
aware we need to make, i.e. update our runtime function pointer to its
efi_va during SetVirtualAddressMap, at least from a kexec perspective.

- Alex

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ