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.