Re: Restricting rdtsc [was: kernel aslr]

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

sorry for the delay

Le 31/03/2017 à 19:23, Andreas Gustafsson a écrit :
> It's ASLR that's broken, not rdtsc, and I strongly object to
> restricting the latter just to that people can continue to gain
> a false sense of security from the former.

For your information, side-channels are not only limited to aslr. It has
been demonstrated too that cache latencies can be used to keylog a privileged
process, and to steal cryptographic keys.

Le 28/03/2017 à 23:17, Mouse a écrit :
> I suspect you aren't being imaginative enough. :-)
>
> If I were to do this, I would first make (or arrange for) compiler
> options so that all memory references - both data references and
> jump/call targets - are done relative to a base register.  The kernel
> is built that way.  Then, whenever we want to, we (a) fiddle the MMU
> and (b) change that register.  Instant kernel relocation!

This is not part of being imaginative, it is called segmentation, and it was
abandoned twenty years ago. The principle was exactly what you are describing:
each memory reference would be indexed by a segment register (%cs %ds etc),
that had a base address and limit. Originally it was used to provide privilege
separation; later, when paging was introduced, each operating system switched
to the flat-memory model (base = 0, limit = maximum). Now, the amd64 hardware
does not enforce the base and limit on several segment registers.

If you remember the USER_LDT thread from a few weeks ago, the problem with our
amd64 is precisely that we expect segment registers to be useless, and therefore
we don't allow them to have different values than the static flat-memory ones.
The problem is, under netbsd32+USER_LDT, segment registers are useful.

Even if they were still available on amd64, there would be a number of different
workarounds to apply in order to maintain consistency with paging, which in
short may have an important performance impact.

Apart from segment registers, you won't find a simple way of indexing memory
references; so no, this is not workable.

Le 29/03/2017 à 01:17, Thor Lancelot Simon a écrit :
> This will break a ton of stuff.  Code all over the place checks if it's
> on x86 and uses rdtsc when it wants a quick timestamp.

There is no code "all over the place" that uses rdtsc; just look at NXR, we
don't have any program in base that uses it. It is like RWX pages and
pax_mprotect, or even mapping NULL; some programs need to be special-cased, but
apart from that it does not create a huge mess.

Le 29/03/2017 à 00:49, Alexander Nasonov a écrit :
> I think this should be either all-or-nothing. You either have rdtsc as
> a time source or you don't. Similar for rdpmc (and other performance
> counters).

Well, the idea was to make the availability more fine-grained.


Seeing the general skepticism that prevails, I guess we can just forget about
this idea.