linux-kernel - Re: [PATCH] phys_efi_set_virtual_address

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: <20120621165220.GQ3464@sgi.com>
Date:	Thu, 21 Jun 2012 11:52:20 -0500
From:	Robin Holt <holt@....com>
To:	"H. Peter Anvin" <hpa@...ux.intel.com>
Cc:	Robin Holt <holt@....com>, Matthew Garrett <mjg59@...f.ucam.org>,
	linux-kernel@...r.kernel.org,
	"Sakkinen, Jarkko" <jarkko.sakkinen@...el.com>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
Subject: Re: [PATCH] phys_efi_set_virtual_address_map needs va, no pa.

On Wed, Jun 20, 2012 at 05:46:49PM -0700, H. Peter Anvin wrote:
> On 06/20/2012 05:27 PM, Robin Holt wrote:
> > 
> > What do you need from me?  If you want me to help with this, I have a
> > _WHOLE_ lot of learning to do.  Can you give me any pointers?
> > 
> > We are trying to get this finally fixed.  We have had work-around code
> > in SLES11 SP1, SLES11 SP2, and RHEL 6.x.  I would love to get this fixed
> > for future distro snaps.
> > 
> 
> If you want to tackle it, the task is basically that when we modify the
> pgds in 32-bit legacy (non-PAE) mode, we should make the corresponding
> modifications to initial_page_table, and in 64-bit mode to
> real_mode_header->trampoline_pgd.  It might be worthwhile to introduce a
> common pointer for both, obviously.

I am completely lost as to what should be done.  How do we know
which identity maps need to be created?  Do we just add them as we are
scanning the e820/EFI memory maps and include the reserved, etc ranges?
Do we look at the table handed to us by EFI at the beginning of boot and
use that as the basis?  Or do we simply wait until the kernel's memory
initialization is complete and cover all of physical memory from zero
up to the highest physical address?

> This is currently handled via something called the pgd_list (when we
> update the top level kernel address space we walk pgd_list and update
> them all), but there are two issues:
> 
> 1. Obviously, in the case of the 1:1 map, we don't just need to maintain
> the kernel area, but the "user space" part of the address space should
> contain a copy, as well.
> 
> 2. To complicate things, there is code in there to grab an mm lock for
> the benefit of Xen.  The 1:1 map doesn't have an mm associated with it,
> so I'm not quite sure how that is to be handled.  Perhaps Xen just plain
> won't need it and we can just bypass it, but I have no bloody idea.
> 
> It is also a bit "cute" how we seem to make a function call to indirect
> through a pointer (why on Earth is pgd_page_get_mm() not an inline?!),
> and then grab a lock unconditionally, regardless of if we are affected
> by Xen or not.
> 
> 	-hpa
--
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/