linux-kernel - Re: Fwd: [PATCH] x86: Use larger chunks in mtrr

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: <1441322474.3277.78.camel@hpe.com>
Date:	Thu, 03 Sep 2015 17:21:14 -0600
From:	Toshi Kani <toshi.kani@....com>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
Cc:	Prarit Bhargava <prarit@...hat.com>,
	Stuart Hayes <stuart.w.hayes@...il.com>, tglx@...utronix.de,
	mingo@...hat.com, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org, x86@...nel.org,
	mcgrof@...not-panic.com, Toshi Kani <toshi.kani@...com>,
	Jan Beulich <JBeulich@...e.com>,
	Juergen Gross <jgross@...e.com>
Subject: Re: Fwd: [PATCH] x86: Use larger chunks in mtrr_cleanup

On Fri, 2015-09-04 at 00:45 +0200, Luis R. Rodriguez wrote:
> On Thu, Sep 03, 2015 at 04:25:31PM -0600, Toshi Kani wrote:
> > On Fri, 2015-09-04 at 00:07 +0200, Luis R. Rodriguez wrote:
> >  :
> > > These are still at odds, for instance, I was under the impression we can
> > > just have the OS return MTRR_TYPE_INVALID if the OS / drivers never used
> > > or set up MTRR, but the platform did, above (not the patch) you seem to 
> > > be saying that even if the OS didn't modify MTRRs the OS still needs to
> > > return the appropriately set up MTRR type by firmware. This is 
> > > different. Can you clarify?
> > 
> > mtrr_type_lookup() returns valid MTRR cache type for a given address range
> > when MTRRs are enabled.  It does not matter if MTRRs are set by the 
> > firmware or the OS.  When MTRRs are enabled, the kernel needs to check 
> > through mtrr_type_lookup() that large page mapping requests are aligned 
> > with MTRRs.
> 
> One further change I was considering was seeing if we can separate PAT
> set up from MTRR's setup, but that was under the assumption we could live
> with a kernel that would have mtrr_type_lookup() return MTRR_TYPE_INVALID
> if kernel MTRR code is completely disabled but PAT enabled. We can't enable 
> PAT today without MTRR beceause PAT is initialized from the MTRR init 
> sequence and that depends on MTRR, if we separated these though and and if a 
> distro disabled kernel MTRR an but enabled PAT and if MTRR did set up MTRR 
> what would the possible issues be?

PAT's dependency to MTRR could be removed, but I would not recommend disabling
the MTRR option since most of the firmwares enable MTRRs.  When the kernel has
the MTRR option disabled, but the firmware enables MTRRs, the kernel is unable
to verify if a large page mapping is aligned with MTRRs.  This can lead
undefined behavior when such an unaligned map with MTRRs is created and
accessed.

> > On Xen,
> 
> When Xen is used a platform firmware may still set up MTRR, even if the
> hypervisor doesn't set up MTRR right ? So same issue and question here.

Right, I meant to say Xen guests.  In case of the Xen hypervisor,
mtrr_type_lookup() returns a valid type as it runs on a platform.

Thanks,
-Toshi

> > or on a platform with firmware that does not enable MTRRs,
> > mtrr_type_lookup() returns MTRR_TYPE_INVALID (as long as the kernel does 
> > not enable them).
> 
> Sure this makes sense.
> 
> Thanks in advance,
> 
>   Luis
--
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/