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

Message-ID: <CAB=NE6WiTg00iyMvebj0OcCR+jBjD-e-Fg2AhWsvHG=YayLP_Q@mail.gmail.com>
Date:	Tue, 29 Mar 2016 10:22:15 -0700
From:	"Luis R. Rodriguez" <mcgrof@...nel.org>
To:	David Vrabel <david.vrabel@...rix.com>,
	Toshi Kani <toshi.kani@...com>
Cc:	"Luis R. Rodriguez" <mcgrof@...nel.org>,
	"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 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

>> > in particular UC settings, this concern is raised above.

And the reason for this seems to have been because some BIOSes may
still use a UC MTRR, the BIOS can only use MTRR as the BIOS is in
virtual mode with page tables enabled. Toshi notes that the default
cache attribute is set by setting the MTRR default type MSR, I'm
poking to see if perhaps there is a strategy that can be used to
circumvent the need for actual complex MTRR code in BIOS / platform
code (Xen) (or bare metal) by matching the memory type with PAT's
default and still keep it compatible to enable a functional fan
control [0]

[0] http://lkml.kernel.org/r/CAB=NE6WP2YsVTwypLLGK6Y8KDiV3hxoLM6kvyifV776kUATKGg@mail.gmail.com

>> > Another issue
>> > though is that the kernel would be "unable to verify if a large page
>> > mapping is aligned with MTRRs" [3]
>>
>> This is not a relevant concern for Xen guests:   PV guests do not
>> support superpage mappings
>
> And only with superpage mappings would such things be an issue? Can you
> clarify why? Is there no plans to support this in the future? If the
> MTRRs will not be used, to be safe, why not just skip all of them from
> the e820 map and be done with it?

I still wonder why then just not skip the entire MTRR from the e820
map, specially if there are uncertainties from the above questions or
if we simply do not wish to mesh up Linux upstream MTRR code to
support a Linux guest type with *only* the requirement of get_mtrr()
-- that would seem really silly to do.

>> and HVM guests never see real MTRRs.
>
> Thanks, can you clarify why?
>
>   Luis

  Luis