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