> Having read several papers on the exploitation of cache latency to > defeat aslr (kernel or not), it appears that disabling the rdtsc > instruction is a good mitigation on x86.
I don't really know x86. But, based on the little I do know, my reactions are: (1) Please provide a kernel build option to remove the restriction. There probably aren't very many systems where fast precise time for nonprivileged users is considered more important than defeating defeating ASLR, but I'd be astonished if there were none. (I'm reminded of the _huge_ performance hit non-executable stack imposed on a few of my programs back when it came in; it was so bad I ended up removing that change from the kernel.) (2) Does that actually help, or does it just compel the attacker to use cruder timers and thus longer test runs? (Or is that enough difference that you believe it would actually help in practice?) (3) Do you maybe want to log something, and/or print to the process's tty and/or the console, so that users whose programs start mysteriously crashing have at least a fighting chance of figuring out why? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B