Le 28/03/2017 à 20:32, Mouse a écrit :
But, by repeating observations, it is possible to detect signals well below the apparent noise floor. [...] my question was essentially asking whether you believe the increase in work factor would be enough to make it infeasible.
Theoretically, it does indeed only increase the work factor. I don't have a clear answer on how big this factor is; but as a comparison, one of the papers I found demonstrated that fuzzing the counter with a delta increased the average time of computation from five minutes to ten years, while this is a relatively simple technique. Now, if we take into account the entropy of having a software-based time source (scheduling, interrupts, locks, TLB/cache hits/misses), I would naively say the increase in work factor is a good deterrent. But I agree that demonstrating it would require more research than the effort I'm currently putting into it. Le 28/03/2017 à 20:32, Mouse a écrit :
Hence also my question about changing the kernel's location at runtime. If the address space base changes every second, say, any technique to discover it that takes longer than a second becomes useless.
I already thought about this a few months ago, and my conclusion back then was that it is very difficult to achieve if we want both good performance and good security. This is a little off-topic, but the idea would consist in having two identical kernel text segments mapped at different addresses. Only one kernel is active at a time. Every once in a while we randomize the other kernel, wait for interrupts to happen in the currently running lwps, and migrate these lwps to the new kernel, dropping refcounts along the way. When it reaches zero, everybody uses the new kernel, and we unmap the previous one. And we keep jumping between kernels this way regularly. I also had other magic tricks for .data and .rodata, but that's another debate. Le 28/03/2017 à 20:37, Taylor R Campbell a écrit :
Put barriers in the way of legitimate applications to thwart hypothetical attackers who will... step around them and use another time source, of which there are many options in the system? This sounds more like cutting off the nose to spite the face than a good mitigation against real attacks.
Kind of, but so far it is the only viable fix. Other mitigations exist, such as flushing caches on each context switch, preventing two threads in the same process from being scheduled together on a single cpu, detecting intentional races that betray a side-channel attack, etc., but each of these seems complicated to implement and may drastically impact performance, while not being particularly more efficient than just restricting rdtsc. As Paul said the real solution would be to change the "algorithm", but it is up to the vendors to do so. There's nothing else I can tell you here.
