linux-kernel - Re: [Xen-devel] MTRR on Xen - BIOS use and implications for Linux

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] [day] [month] [year] [list]

Message-ID: <20160329222815.GB1990@wotan.suse.de>
Date:	Wed, 30 Mar 2016 00:28:15 +0200
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	Toshi Kani <toshi.kani@....com>
Cc:	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	David Vrabel <david.vrabel@...rix.com>,
	Toshi Kani <toshi.kani@...com>,
	"xen-devel@...ts.xensource.com" <xen-devel@...ts.xensource.com>,
	Keir Fraser <keir@....org>, Juergen Gross <jgross@...e.com>,
	X86 ML <x86@...nel.org>,
	Andrew Cooper <andrew.cooper3@...rix.com>,
	Stuart Hayes <stuart.w.hayes@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Borislav Petkov <bp@...en8.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Paul McKenney <paulmck@...ux.vnet.ibm.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Prarit Bhargava <prarit@...hat.com>
Subject: Re: [Xen-devel] MTRR on Xen - BIOS use and implications for Linux

On Tue, Mar 29, 2016 at 04:14:41PM -0600, Toshi Kani wrote:
> On Tue, 2016-03-29 at 10:22 -0700, Luis R. Rodriguez wrote:
> > On Thu, Mar 17, 2016 at 11:56 AM, Luis R. Rodriguez <mcgrof@...nel.org>
> > wrote:
> > > On Thu, Mar 17, 2016 at 11:13:03AM +0000, David Vrabel wrote:
> > > > On 16/03/16 20:08, Luis R. Rodriguez wrote:
> > > > > Toshi noted a while ago as well that if BIOS/firmware enables MTRR
> > > > > but the kernel does not have it enabled one issue might have been
> > > > > any MTRRs set up by the BIOS and ensuring the mapping is respected,
> > 
> > To be clear the requirement expressed here was needing at least to
> > implement get_mtrr() on the Linux Xen guest side, it'd call the
> > already implemented hypercall XENPF_read_memtype in turn. Toshi had
> > hinted this was perhaps needed on the Linux Xen guest side given that
> > the BIOS may have set up MTRRs on its own, so we needed the guest to
> > be able to get the right type for a particular range. More on that
> > below
> 
> No, I did not say that. :-)  I said it because you mentioned that you
> wanted to disable MTRRs even though BIOS enabled MTRRs.
> 
> My point is that the kernel should not change the MTRR setup.  That is:
>  - If BIOS enables MTRRs, then kernel needs to keep them enabled.
>  - If BIOS disables MTRRs, then the kernel needs to keep them disabled.
> 
> Therefore, the kernel can keep MTRRs disabled on Xen guests.

Indeed, thanks for the clarification. That knocks this last concern
out of the way. The remaining aspects then are simply optimizations
considerations.

  Luis