Re: Restricting rdtsc [was: kernel aslr]

[Maxime Villard <max%m00nbsd.net@localhost>]

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.