linux-kernel - Re: [PATCH] x86, pat: Add comments to cachemode translation tables

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: <1437665107.3214.310.camel@hp.com>
Date:	Thu, 23 Jul 2015 09:25:07 -0600
From:	Toshi Kani <toshi.kani@...com>
To:	Jan Beulich <JBeulich@...e.com>
Cc:	peterz@...radead.org, mingo@...nel.org, x86@...nel.org,
	tglx@...utronix.de, bp@...e.de, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86, pat: Add comments to cachemode translation tables

On Thu, 2015-07-23 at 08:50 -0600, Jan Beulich wrote:
> > 
> > > > On 23.07.15 at 16:27, <toshi.kani@...com> wrote:
> > On Thu, 2015-07-23 at 00:42 -0600, Jan Beulich wrote:
> > > > 
> > > > > > On 22.07.15 at 20:06, <toshi.kani@...com> wrote:
> > > > Add comments to the cachemode translation tables to clarify that
> > > > the default values are set as minimal supported mode, which are
> > > > necessary to handle WC and WT fallback to UC- when they are not
> > > > enabled.
> > > 
> > > Wait - shouldn't WT fall back to UC (so to not be affected by WC
> > > MTRR settings)?
> > 
> > Well, when MTRR is set to WC, WT will become UC.  So, it is not safe to
> > start with.
> 
> Hmm, considering how my question was meant, your reply looks
> contradictory to me. What I was talking about is the table as it is
> in RC3, i.e. WT mapping to PAGE_PCD (matching WC and
> UC_MINUS). I.e. if a page is mapped WT (i.e. UC-) and the
> MTRRs for it say WC, then the result will be WC. Whereas if
> WT translated to PAGE_PWT|PAGE_PCD (i.e. matching UC), an
> MTRR setting of WC would have no effect - the resulting type
> would still be UC.

Yes, I know what you meant.  I agree that WT should fall back to UC when
considering MTRR. 

In my reply, I was referring the regular case that WT is supported (i.e. no
fallback).  WT request to a range covered by MTRR with WC will become UC. 
 I think such code is not written properly (I should not have said "not
safe") since it won't get WT in the regular case, either.  A range with
MTRR covered by WC is a special memory, ex. frame buffer, and the code
should know what type of memory it is dealing with.

> > I know Luis is driving to support UC.  When UC can be used for both 
> > regular
> > memory and IO memory, yes, it can be changed to fall back to UC.  At 
> > this
> > point, however, UC cannot be set to regular memory.  See
> > reserve_ram_pages_type().
> 
> With the above in mind, that's a problem then I would say.
> Yet no matter whether UC can't be expressed as an
> attribute on a page, what gets stored in the page table
> entries should, together with how PAT is set, result in
> something that doesn't weaken the requested memory
> type. I.e. if WT was requested, the end result shouldn't
> be WC. Yet any representable type may still be mapped to
> UC (as being the strictest one possible), and hence if WT
> can't be expressed it should be made UC.

Yes, I agree with you.  But such risk is very low -- 1) the regular case
(no fallback) is used most of the cases, 2) the code using WT knows what
type of memory it is dealing with.  For example, pmem may map NVDIMM with
WT, and any sane BIOS sets MTRR to WB for NVDIMM. 

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/