On Thu, Jan 8, 2015 at 7:28 PM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: >> > > It even has a CVE (CVE-2014-9419). > > Every fart can get a CVE these days. > >> attack may only work against 32-bit targets. Maybe we should just get >> rid of the fsbase/gsbase-via-GDT optimization. (If we did that, then >> we could go farther and turn TLS off entirely on non-compat kernels.) > > Sorry, but this is just crazy talk. Just don't go there. > >> >> Andi, I think the 64-bit TLS code. Do you recall what the <4GB >> optimization is for? > > To avoid the WRMSR penalty on the context switch. > > It is obsolete with the WR*BASE patchkit. > >> Hmm. On my system, both PIE and non-PIE 64-bit executables seem to >> put their TLS base in mmap space, which is far above 4GB. So this > > Yes some recent systems have broken the optimization. But it still > helps in a lot of cases. > Are there any up-to-date libc implementations for which the optimization *does* work? It appears that at least glibc and musl use mmap and thereby defeat the optimization. I don't think it's worth keeping around somewhat fragile code to optimize a use case that no longer exists and for which removing the extra code wouldn't break anything. --Andy >> > I indeed can run estest with failures on 3.12. But what does it mean to >> > me would be nice to have explained... > > AFAIK it means nothing. > > -Andi -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html