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: <4A53EC4A.1000403@zytor.com>
Date:	Tue, 07 Jul 2009 17:46:02 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	"John A. Gregor" <john.gregor@...gic.com>
CC:	ralph.campbell@...gic.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86_64/__iowrite32_copy: don't use string move for PIO
 writes

John A. Gregor wrote:
> 
> Anyway, we're very likely going to have to stick with asm for X86_64 no
> matter how it gets implemented both for performance and as protection
> against the compiler generating a rep movs sequence.
> 
> So, I see at least a couple possible courses of action:
> 
> 1. Redefine __iowrite32_copy(), document it better, and take the
>    new asm.
> 2. Delete the .S file, warn about the possibility of the compiler
>    generating a rep movs sequence in the C code, and the ipath driver
>    will have a private copy routine again.
> 

I discussed this with H.J. Lu (x86 gcc maintainer), and he stated rather
unequivocally that gcc will not generate string instructions for a
volatile store, and that the gcc team considers that part of the
definition for volatile.  So the C version is guaranteed to be good; we
should just remove the assembly version.

Redefining a public API -- no matter if you were the original authors --
is not an option.  If you need something other than __iowrite32_copy()
or __iowrite64_copy() you should define a new API or make it a private
one.  Either which way, a C implementation is guaranteed to be safe.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ