linux-kernel - Re: [GIT PULL] xen /proc/mtrr implementation

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:	Sun, 17 May 2009 21:57:40 -0700
From:	Jeremy Fitzhardinge <jeremy@...p.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Ingo Molnar <mingo@...e.hu>,
	the arch/x86 maintainers <x86@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Xen-devel <xen-devel@...ts.xensource.com>
Subject: Re: [GIT PULL] xen /proc/mtrr implementation

Eric W. Biederman wrote:
> There are only 3 states that are interesting.  WB UC and WC.  Since
> Xen controls the page tables anyway.  I expect it can even remap
> it feels like it.
>   

It would be awkward.  A paravirtualized guest has direct access to the 
real pagetables, and so would notice if Xen swizzled around the PAT bits 
when it reads back a pagetable entry.  We don't currently have any 
paravirtualized hooks for adjusting the PTE flags, because there hasn't 
been any need, and it would probably be pretty costly (lots of 
read+bit-tests would turn into a function call).  On the other hand, 
there's probably only a few places (if any) in the kernel which actually 
inspect the PAT status of an established PTE, so we could put in some 
special case mapping there.  It becomes a maintenance burden to 1) track 
down all the right places, and then 2) make sure any new instances get 
handled properly.  So, not a preferred solution, I think.

But our planned approach is to simply make Xen use the same PAT layout 
as Linux, and go from there.  We still need to sort out the details of 
how to handle other Xen guests which use the existing Xen PAT setup, how 
to verify that Xen and the guest kernel are really using the same setup, 
etc.

But since we support the last few year's worth of released versions of 
Xen, we still need to handle the PAT-not-supported case with reasonable 
grace.

> I won't argue that having MTRRs when you can makes sense.  It is a bit
> weird in a vitalized system.

It's not really virtualized.  We're talking about dom0, which is the 
guest domain which has access to the real machine's real hardware; the 
MTRR is part of that.

>   At a practical level there are an
> increasing number of systems for which MTRRs are unusable because the
> BIOS sets up overlapping mtrrs.  With cheap entry level systems
> shipping with 4G I expect it is becoming a majority of systems.
>   

Yes, but that is true irrespective of Xen.

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