linux-kernel - Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

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: <1434151758.2160.98.camel@HansenPartnership.com>
Date:	Fri, 12 Jun 2015 16:29:18 -0700
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Jan Beulich <JBeulich@...e.com>, Juergen Gross <jgross@...e.com>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	Ville Syrjälä <syrjala@....fi>,
	Dave Airlie <airlied@...hat.com>,
	"xen-devel@...ts.xenproject.org" <xen-devel@...ts.xenproject.org>,
	linux-fbdev <linux-fbdev@...r.kernel.org>,
	X86 ML <x86@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	linux-media@...r.kernel.org, Luis Rodriguez <Mcgrof@...e.com>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Toshi Kani <toshi.kani@...com>, Borislav Petkov <bp@...e.de>,
	Julia Lawall <julia.lawall@...6.fr>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	ville.syrjala@...ux.intel.com
Subject: Re: [Xen-devel] RIP MTRR - status update for upcoming v4.2

On Fri, 2015-06-12 at 16:15 -0700, Andy Lutomirski wrote:
> On Jun 12, 2015 12:59 AM, "Jan Beulich" <JBeulich@...e.com> wrote:
> >
> > >>> On 12.06.15 at 01:23, <toshi.kani@...com> wrote:
> > > There are two usages on MTRRs:
> > >  1) MTRR entries set by firmware
> > >  2) MTRR entries set by OS drivers
> > >
> > > We can obsolete 2), but we have no control over 1).  As UEFI firmwares
> > > also set this up, this usage will continue to stay.  So, we should not
> > > get rid of the MTRR code that looks up the MTRR entries, while we have
> > > no need to modify them.
> > >
> > > Such MTRR entries provide safe guard to /dev/mem, which allows
> > > privileged user to access a range that may require UC mapping while
> > > the /dev/mem driver blindly maps it with WB.  MTRRs converts WB to UC in
> > > such a case.
> >
> > But it wouldn't be impossible to simply read the MTRRs upon boot,
> > store the information, disable MTRRs, and correctly use PAT to
> > achieve the same effect (i.e. the "blindly maps" part of course
> > would need fixing).
> 
> This may crash and burn badly when we call a UEFI function or an SMI
> happens.  I think we should just leave the MTRRs alone.

Wholeheartedly agree: PAT only works when the given memory map is in
operation but MTRRs function everywhere.  Anything that goes into real
mode or installs its own memory map won't see the Linux page attributes.

James


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