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: <4FE26EF9.5060004@linux.intel.com>
Date:	Wed, 20 Jun 2012 17:46:49 -0700
From:	"H. Peter Anvin" <hpa@...ux.intel.com>
To:	Robin Holt <holt@....com>
CC:	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 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.

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/