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: Sat, 01 Aug 2009 20:52:06 -0700 From: "H. Peter Anvin" <hpa@...or.com> To: Paul Mackerras <paulus@...ba.org> CC: Linus Torvalds <torvalds@...ux-foundation.org>, Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Tejun Heo <tj@...nel.org> Subject: Re: [GIT PULL] Additional x86 fixes for 2.6.31-rc5 On 08/01/2009 06:20 PM, Paul Mackerras wrote: > When I tried using __thread for per-cpu variables on ppc64, I found > that gcc would sometimes precompute and cache the address of a per-cpu > variable even though it could always access the variable using an > offset from r13. The cached address was wrong if the task got moved > to a different cpu, of course, but there was no way to tell gcc that. > Compiler barriers don't help because they say that the contents of > variables might have changed, but not their addresses. > > So on x86 the concern would be that gcc might do lea %gs:foo,%rbx and > then use (%rbx) to refer to foo later on. It would be possible to use > __thread for per-task variables rather than having to put all per-task > things in the task_struct, but __thread doesn't work for per-cpu > variables in my experience. You can't actually do "lea %gs:foo,%rbx" (lea doesn't include the segment offset, unfortunately; I asked AMD to change that on 64 bits but, not too surprisingly, they weren't able to make that change.) Getting the address is expensive, but it's obviously possible -- which may have similar bad results. It would be worth experimenting with a little bit, though. -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/
Powered by blists - more mailing lists