linux-kernel - Re: WT memory type on x86

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:	Wed, 8 May 2013 10:35:08 -0400
From:	Konrad Rzeszutek Wilk <konrad@...nel.org>
To:	Andy Lutomirski <luto@...capital.net>, stefan.bader@...onical.com
Cc:	linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: WT memory type on x86_64?

On Wed, Apr 24, 2013 at 12:33:33PM -0700, Andy Lutomirski wrote:
> For an upcoming (and, sadly, NDA'd [1]) project, I may need to use
> write-through memory.  I'd like to gauge how unpleasant this will be.
> 
> AFAICT, modern CPUs allow the WT type to be set using MTRR or a PAT
> entry.  Sadly, MTRRs are in short supply, and the four fully-usable
> PAT slots are used for UC, UC-, WB, and WC.  I can keep my fingers
> crossed and hope that there are enough free MTRRs, or I could try to
> free up a PAT entry.
> 
> How nasty will the latter be?  I just looked at two rather different
> modern Sandy Bridge machines, and BIOS doesn't appear to set up any
> MTRRs in the WC or WP states.  As long as those MTRR types aren't
> used, I think the UC- PAT entry is useless -- it behaves identically
> to UC.  Lots of DRM drivers, though, seen to add a WC MTRR to cover
> video memory.  Is there any need for this on modern machines?  That
> is, are there any drivers that actually need the mtrr_add call to
> succeed on a machine that has a working PAT?
> 
> If not, then here's a proposal:  At startup, if there are no WC or WP
> MTRRs and the CPU is new enough, then set a flag for an alternative
> PAT.  In alternative PAT mode, UC- is replaced with WT in the PAT and
> mtrr_add fails when attempting to add a WC or WP entry.  Add
> set_memory_wt, etc.  They fail in non-alternative-PAT mode.  This gets
> a bit unpleasant, since _PAGE_CACHE_UC_MINUS will have a different
> meaning depending on the mode.
> 
> A less conservative proposal would be to stop using UC- in the PAT
> entirely.  The memtype code could learn to emulate UC- when there's an
> overlapping WC or WP MTRR.
> 
> Any thoughts?  Are there known errata here?  Is there a good reason
> why the kernel needs UC-?  Will this be such a big can of worms that I
> should just hope there's an available MTRR?

Stefan Bader (CC-ed here) was looking in making a "black-box" type
code wherein for any types but WC it would lookup in the PAT index
the right bit and provide that for the page_attr_set functions.

If I recall he had run in a bit of issue with of the hard-coded values
set by the macros.

> 
> --Andy
> 
> [1]  I hope to be able to upstream all kernel code related to this
> project.  It will be neat -- I promise.  It will depend on convincing
> the people on the other end of the NDA that they should let me.
> --
> 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/
> 
--
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/