Re: CVS commit: src/sys/arch/x86/x86

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Tue, Oct 03, 2017 at 08:17:27AM +0200, Maxime Villard wrote:
> What is clear, however, is that the effort needed to perform accurate
> measurements in software is much higher than that needed to invoke a hardware
> instruction that will instantly give about the most accurate answer possible.

Have you tried getting reliable answers out of rdtsc lately? It is
suprisingly difficult. TSC is nice for two properties:
- it is cheap as in it consumes few cycles by itself
- it has a high resolution

At the same time, it has interesting interactions with power management
and the instruction queue. As such, "the most accurate answer" is not
true either.

> Disabling rdtsc is almost the only thing we can do; we can't update the
> hardware to kill the variable timing.

Variable timing won't go away. Any "security" technique that can't deal
with it is doomed to failure.

> An additional thing we could do, if
> we had proper NUMA support, would be to add a mode where the kernel schedules
> unprivileged applications on a cluster, and the rest of the kernel and suid
> LWPs on the other clusters. But that's far, far from us.

It would also kill performance. Again, cycle timing rarely matters and
hiding the TSC won't fix any of the cases where it does. Those are
algorithmic issues. Hiding the TSC can make it harder to apply noise in
those unfixable cases though.

> So the sysctl is here, and is enabled. People don't need to care about it by
> default. The use case I see is for ssh servers running kaslr kernels.

Hiding the TSC doesn't solve any problem for this configuration. All
this sysctl provides is a very false sense of security and a way to
randomly break applications. That means it creates a support cost for
little to no gain.

Joerg