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

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

Le 03/10/2017 à 00:09, Taylor R Campbell a écrit :
> > Date: Mon, 2 Oct 2017 21:42:11 +0200
> > From: Joerg Sonnenberger <joerg%bec.de@localhost>
> >
> > On Mon, Oct 02, 2017 at 07:23:16PM +0000, Maxime Villard wrote:
> > > Add a machdep.tsc_user_enable sysctl, to enable/disable the rdtsc
> > > instruction in usermode. It defaults to enabled.
> >
> > Do we really need this change? I've said it before, I consider this a
> > really stupid idea and effectively useless complexity. rdtsc is not
> > necessary for precision measurement as long as an attacker is willing to
> > waste CPU time, i.e. having one core spinning incrementing a counter and
> > reading that one of a second core will give fairly accurate measurements
> > as long as both cores are near each other. It's normally not that
> > difficult to ensure that.
>
> Concur.  The way to thwart timing side channel attacks is not to
> pretend attackers don't have stop-watches; it's to avoid the variable
> timing that creates the side channels in the first place.

Well, basically, I agree with you - that it is security by obscurity, that
there are other ways to perform measurements, that the variable timing is what
needs to be fixed, and I also believe that my idea of making rdtsc privileged
was dumb.

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.

Disabling rdtsc is almost the only thing we can do; we can't update the
hardware to kill the variable timing. 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.

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.

As a side note, finally, please be reminded that hardware cache attacks are
still exotic and non deterministic techniques, and that an attacker will
probably just try to find a leak in a syscall instead to deterministically
get a valid VA.

Maxime