Re: Restricting rdtsc [was: kernel aslr]

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> There is however another technique (software clock) to try to compute
> the number of cycles an operation takes, but the resulting accuracy
> is very low, and not sufficient to detect cache misses via latency.

> [D]etecting cache misses implies having a precision of at least ~50
> cycles, and only rdtsc offers this precision.  Syscalls and other
> software-based timers have a non-deterministic overhead that is
> bigger than ~50 cycles, and it therefore pollutes the relevant
> information.

But, by repeating observations, it is possible to detect signals well
below the apparent noise floor.  NTP does this with timekeeping
(submicrosecond accuracy over network paths having tens of microseconds
of latency jitter).  GPS receivers do similar things with radio
reception.  I have little-to-no faith that this change would do more
than raise the work factor; my question was essentially asking whether
you believe the increase in work factor would be enough to make it
infeasible.  I am pessimistic on that question, given how long stealthy
malware has been known to run on machines without being noticed.

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.

Of course, this is all about something that is, really,
belt-and-suspenders.  That doesn't make it useless, but it _is_ a
second layer, not a primary defense.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B