Subject: Re: pidentd
To: Hubert Feyrer <hubert.feyrer@rz.uni-regensburg.de>
From: Marc Slemko <marcs@znep.com>
List: tech-pkg
Date: 04/05/2000 22:46:24
On Thu, 6 Apr 2000, Hubert Feyrer wrote:

> 
> I've spent some time trying to get a identd for IPv6 done, but didn't
> really succeed. The package at
> http://www.feyrer.de/Misc/pidentd-3.1a14-pkg.tgz
> builds for v4 currently, but does not deal with v6 properly (you need to
> set USE_INET6=NO in /etc/mk.conf).
> 
> If someone wants to have another look at k_bsd42.c and fix the v6
> handling, that would be nice. I'll also send my patches to the author,
> maybe he'll help us out (but I doubt that - the kvm-grovling stuff is
> OS-specific, and we don't even seem to be compatible to FreeBSD there :/).

While this is a bit beyond what you are trying to accomplish, if someone
is working on identd they should really consider taking the extra effort
to get it right...

kvm is really the wrong way to do identd, or nearly anything.  No kvm
based identd can ever be safe or reliable.  In fact, I had some very nasty
experiences with kvm based identds on a BSDI box; they would routinely
hang the entire box hard under heavy use.

What was happening in this case is that, due to the implicit race
conditions in using kvm since it can't do any locking of kernel data
structures, it tried reading from an address around 0xffff0000; this isn't
a very random address, so the right sort of race condition can make you
get it a lot.  Normally, that would just make your identd choke or go into
an infinite loop.  However, on BSDI, the SMP IO APIC is mapped from
0xffff0000 to 0xffff0fff or so.  Reading from certain addresses that are
mapped to the APIC can hang the machine hard.  In general, reading from
arbitrary kernel memory isn't a safe thing to do, and that is what any kvm
based solution has a chance of doing.

My hack on BSDI was to hardcode identd so if it was going to try reading
from a kernel memory address between 0xffff0000 and 0xffff0fff, it would
just complain and die.  Sure doesn't fix the problem, but it avoided the
hangs.  Unfortunately, a more robust solution wasn't possible without
kernel changes.

What FreeBSD has to be able to do things in a better way is a sysctl that
gives an opaque type back that contains all the necessary info on open
sockets.  I'm not sure I am entirely thrilled with that either, since it
offers a lot of information to random users and the interface isn't too
clean, but at least it gives reliable info and won't crash the machine.