Re: Restricting rdtsc [was: kernel aslr]
Maxime Villard wrote: > 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. There are two more or less independent things: fine-grained time source and userspace rdtsc. The latter is often used directly when vdso isn't available. If we implement vdso, I assume that software that needs rdtsc can be taught to call it via vdso. With vdso implemented, we can have a flag that enables/disables vdso globally as well as per process (paxctl?). Independetly, the kernel can be configured to use either fine-grained or hackerproof time source for regular (non-vdso) system calls. Alex
Re: Restricting rdtsc [was: kernel aslr]
On Tue, Apr 04, 2017 at 05:39:35PM +0200, Maxime Villard wrote: > 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. Time is a basic operating system service. Lack of cheap precision time is not an _advantage_ of NetBSD; it is a disadvantage. As others have noted, our general intention has been to _reduce_ the cost to an applicaiton of obtaining timestamps in general -- by providing a commpage with a base value, and allowing libc to use the cycle counter as a no-system-calls-required way to obtain an offset. Other operating systems do this and it is a real advantage for many applicaitons. If we block userland access to the cycle counters, this is a nonstarter. Yes, the ability of malicious code to measure the behavior of critical system components and facilities is a problem, but I tend to believe the solution has to be in the implementation of those components and facilities, not in removing the ability of non-malicious code to make precision measurements. We may not have applications in base that use use rdtsc to get quick timestamps, but they're sure out there. OpenSSL's MD code used to use it -- has that changed? -- and I've seen it in database applications, language runtimes, and numerous other places. I really don't think it would be a good idea to cause it to not work in the general case. Thor
Re: Restricting rdtsc [was: kernel aslr]
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.
Workqueues on filesystems
Hi, I'd like to tackle LFS issues. I've been running it as my root filesystem to get some real world testing, and it often wedges, and this with heavy use of KERNEL_LOCK (it's not marked MPSAFE). I'm still getting to know it, and not there yet. I don't feel comfortable with how it has its own implementation of serialization etc, and would like to change it to use existing APIs where they fit. Playing with networking I used workqueue(9) which I think is perfect for e.g. LFS writer daemon, but its use is currently limited to networking code deferring work from interrupt handlers, that was the original intention of it. Is there a reason I shouldn't use it for LFS? Thanks.
Re: Add a mountlist iterator (round 2)
Time to start a second round. This time the iterator only, vfs_busy()
and friends deferred to a new thread once the iterator is done.
Changes from the previous proposal:
- Removed the "flags" argument from mountlist_iterator_next(), will
add mountlist_iterator_trynext() and vfs_trybusy() when needed.
- Added "void mountlist_iterator_done(mount_iterator_t *)" to
completely hide vfs_busy()/vfs_unbusy() from the API and make it
possible to assert that every call to mountlist_iterator_next()
gets accompanied by a call to mountlist_iterator_done().
- Use the existing lock "mountlist_lock".
A typical usage is:
mount_iterator_t *iter;
mountlist_iterator_init(&iter);
while ((mp = mountlist_iterator_next(iter)) != NULL) {
...
mountlist_iterator_done(iter);
}
mountlist_iterator_destroy(iter);
Diffs are here: https://www.netbsd.org/~hannken/ml_iterator2/
Comments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
