linux-kernel - Re: [RFC Patch] use MTRR for write combining if PAT is not available

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>] [day] [month] [year] [list]

Message-Id: <200910132306.00089.thomas.schlichter@web.de>
Date:	Tue, 13 Oct 2009 23:05:59 +0200
From:	Thomas Schlichter <thomas.schlichter@....de>
To:	Eric Anholt <eric@...olt.net>
Cc:	Thomas Hellstrom <thellstrom@...are.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>,
	"dri-devel@...ts.sourceforge.net" <dri-devel@...ts.sourceforge.net>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Yinghai Lu <yinghai@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>,
	Venkatesh Pallipadi <venkatesh.pallipadi@...el.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>,
	Jan Beulich <jbeulich@...ell.com>, Tejun Heo <tj@...nel.org>,
	Jesse Barnes <jbarnes@...rnes-g45>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	Robert Hancock <hancockrwd@...il.com>
Subject: Re: [RFC Patch] use MTRR for write combining if PAT is not available

Eric Anholt wrote:
> On Mon, 2009-10-12 at 21:45 +0200, Thomas Schlichter wrote:
> > Yes, maybe this patch tries to change current behavior too less. Indeed,
> > if setting up MTRR entries it simply behaves as today, and userspace does
> > not see that write combining is not correctly enabled.
> 
> I'm uncomfortable with this patch because it doesn't appear to cover any
> callers of these functions inside of the kernel.  Have you audited them
> to make sure they can handle NULL being returned?

No, I haven't. And to be honest, I think the earlier patch that adds MTRR 
entries should be more safe, as it modifies behavior only slightly.

> Seems like we should install an MTRR instead.  Requiring userland to set
> up the MTRR on the kernel's behalf is backwards.

Exactly.

> With modern drivers we're installing any required MTRRs at module load
> in the kernel, and that's where things should be moving.

I think in general this is not possible, because not for all graphics chips 
there are kernel drivers (required). E.g. for my VIA VX800 based notebook, 
there is no kernel module that should be responsible to set-up the MTRR 
entries. Here it's up to the (userspace) X.org driver. It opens the 
/sys/bus/pci/devices/.../resource0_wc device and mmaps the framebuffer memory. 
With PAT this will set up a write combining memory area, and with my first 
patch this should also happen without PAT with MTRR.

> As long as
> this doesn't interfere with them, I'm OK.  And if some kernel driver is
> failing to install its MTRR, well, let's fix it.

Well, I think the mtrr_add inside mmap should not do any harm...

Kind regards,
  Thomas
--
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/