linux-kernel - Re: [PATCH] x86_64/__iowrite32_copy: don't use string move for PIO writes

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:	Fri, 10 Jul 2009 08:07:13 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Pavel Machek <pavel@....cz>
CC:	"John A. Gregor" <john.gregor@...gic.com>,
	ralph.campbell@...gic.com, linux-kernel@...r.kernel.org,
	johng@...mond.mv.qlogic.com, Hongjiu.lu@...el.com
Subject: Re: [PATCH] x86_64/__iowrite32_copy: don't use string move for PIO
 writes

Pavel Machek wrote:
>> - the current code is fine as long as it doesn't cross from cached to
>>   uncached memory, which it never should in any kind of sensible driver;
> 
> Should we add a comment somewhere saying that is not permitted (and why)?

It sounds like what we should do is simply remove
arch/x86/lib/iomap_copy_64.S, and probably add a comment to
lib/iomap_copy.c stating that rep string instructions have been reported
to cause anomalies when accessing WC memory, and that we rely on gcc not
generating them due thanks to the volatiles in the implementation of
__raw_writel().  H.J. Lu tells me that gcc will not generate string
instructions for volatiles, and that the x86 gcc team considers that
part of the definition for volatile.  (HJL: please correct if I got that
incorrect.)

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

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