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

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

Le 03/10/2017 à 13:26, Joerg Sonnenberger a écrit :
> At the same time, it has interesting interactions with power management
> and the instruction queue.

The queue is flushed by a serializing instruction executed right before, which
is the recommended use case; the interaction with power management - and
by this I suppose you mean that some bioses change the cpu frequency depending
on the battery, temp, etc - also affects the software clock an attacker might
be running. In either case, rdtsc remains more accurate.

> > 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.

no, but that's a different debate, so I'm leaving it there

> Hiding the TSC doesn't solve any problem for this configuration.

solves problems, no; makes it harder to exploit problems, yes

> All this sysctl provides is a very false sense of security and a way to
> randomly break applications

Just like disabling va0 or enabling PaX mprotect; if you feel like these are
no issues, then what's the fuss. You would be well served to read the "rdtsc
is still enabled by default" part of my email.

I'm not responding to this nonsensical thread anymore, everything got told
months ago. The option is here, people don't need to give a damn about it
unless they explicitly want to - which is still legitimate in some cases,
including for kaslr, whether it pleases you or not. There are plenty of
useless sysctls to complain about if you like.