linux-kernel - Re: [GIT PULL] x86/uapi for 3.8

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 18 Dec 2012 08:02:01 +0000
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"H. Peter Anvin" <hpa@...ux.intel.com>
Cc:	"Arnd Bergmann" <arnd@...db.de>, "Ingo Molnar" <mingo@...e.hu>,
	"Michael Kerrisk" <mtk.manpages@...il.com>,
	"Guennadi Liakhovetski" <g.liakhovetski@....de>,
	"Matt Fleming" <matt.fleming@...el.com>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	"Dave Jones" <davej@...hat.com>,
	"David Howells" <dhowells@...hat.com>,
	"Grant Likely" <grant.likely@...retlab.ca>,
	"Markus Trippelsdorf" <markus@...ppelsdorf.de>,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] x86/uapi for 3.8

>>> On 17.12.12 at 18:15, "H. Peter Anvin" <hpa@...ux.intel.com> wrote:
> On 12/17/2012 09:03 AM, Jan Beulich wrote:
>>>>> On 17.12.12 at 17:39, "H. Peter Anvin" <hpa@...ux.intel.com> wrote:
>>> Right, I think you nailed this one.  This patch copies PTEs from the
>>> kernel PTEs and thus they will have the global bit set.  It obviously
>>> makes no sense to *copy* PTEs from the kernel and yet leaving the global
>>> bit set, which means there are two ways of fixing it: either sharing
>>> page tables and use the cr4.pge off/on trick that Jan mentioned -- this
>>> would also be my preference -- and the other is to copy the PTEs but
>>> strip the global bit, which has the advantage that the actual kernel
>>> mappings will survive.
>> 
>> PTE copying is only one half of it. I think additionally L4 entries
>> get copied for the 1:1 mapping, and you can't strip the global
>> bits there without allocating separate page tables.
>> 
> 
> The point right now is that it *does* allocate separate page tables, but

My point was that this isn't really the case: You only considered
the ioremap() adjustment of the respective patch, but the first
of the two loops the same patch adds to setup_real_mode() does
in fact share page tables for the identity mapping of RAM.

Matthew - that loop is, btw, off by one, i.e. should be

       for (i = 0; i <= pgd_index((max_pfn - 1) << PAGE_SHIFT); i++) {

But of course this, at least for the moment, is only a theoretical
issue.

> doesn't take advantage of it.  What I say is I think we should take the
> flush for the advantage of sharing page tables.  If we are allocating
> new page tables then we should of course make them non-global.
> 
> Do we know how often this gets called?  I presume the most common case
> is when we have an EFI RTC?  Unless there is a use case where this
> happens a lot sharing seems much easier...

When running on EFI any access to the real time clock will go
that route (i.e. there is no such thing as EFI without EFI RTC).

But then again there of course shouldn't be frequent accesses
to the RTC in the first place (which otherwise would quickly
become a bottleneck with the CMOS RTC as well).

Jan

--
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/