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

On Thu, 2015-06-11 at 13:36 -0700, Luis R. Rodriguez wrote:
 :
> Pending RIP MTRR patches
> ====================
> 
> There are a few pending series so I wanted to provide a status update
> on those series.
> 
> mtrr: bury MTRR - unexport mtrr_add() and mtrr_del()
> 
> This is the nail on the MTRR coffin, it will prevent future direct
> access to MTRR code. This will not be posted until all of the below
> patches are in and merged. A possible next step here might be to
> consider separating PAT code from MTRR code and making PAT a first
> class citizen, enabling distributions to disable MTRR code in the
> future. I thought this was possible but for some reason I recently
> thought that there was one possible issue to make this happen. I
> suppose we won't know unless we try, unless of course someone already
> knows, Toshi?

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.

UEFI memory table has memory attribute, which describes cache types
supported in physical memory ranges.  However, this information gets
lost when it it is converted to e820 table.

Thanks,
-Toshi

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

Powered by blists - more mailing lists