On Thu, Sep 20, 2012 at 07:58:51AM -0400, John Baldwin wrote: > On Thursday, September 20, 2012 6:21:04 am Pawel Jakub Dawidek wrote: > > I agree, we should do such analysis for much more devices and different > > kind of devices. A platform might be an important factor as well. > > It is hard to collect decent number of probes when reboot is needed, so > > what I'd recommend is to turn of SMP, boot into single module and > > kldload/kldunload a driver in a loop, of course with kernel patched to > > log those times. > > This is not always representative. Any driver that uses a config intrhook > will run that synchronously during attach() in single user mode but will > not during boot. config intrhook's often go out and do things that take a > variable amount of time (poking hardware, waiting for interrupts, etc.). > That means that timing any such drivers from single user mode will likely > give you more variable attach() times than would occur during boot.
Ok, to verify that I implemented some dummy driver that simply returns 0
on device_attach() and does nothing more. Additionally during probe I
call device_quiet(dev). It turned out that printing device description
during device_attach() over serial console (115200) make the call few
orders of magnitude longer:), which in turn provides much more entropy
so I wanted to avoid that.
I booted the machine with SMP disabled and in single-user mode.
I gathered 162833 samples:
http://people.freebsd.org/~pjd/misc/device_attach_total_time.txt
The values were between 15 and 16 bits, but to simplify things I assumed
they are all 16 bits. I discarded top ten bits. This left me with 6bit
values [0-63]:
http://people.freebsd.org/~pjd/misc/device_attach_6bit.txt
I compared empirical distribution with theoretical one and I got this:
http://people.freebsd.org/~pjd/misc/device_attach_6bit.jpg
Source in libreoffice:
http://people.freebsd.org/~pjd/misc/device_attach_6bit.ods
Mariusz can verify my findings here, but it looks like discarding top
ten bits is enough even for very dummy drivers that don't interact with
hardware at all.
Note that discarding top ten bits effectively means that we expect 0.1%
of the total device_attach() time to be unpredictably different.
If discarding top ten bit in case of such dummy driver is enough, we
could probably discard less from drivers that interact with real
hardware, but even with 43 device_attach() calls during boot on similar
hardware and assuming that we can get only 6 bits of entropy from each
call, it gives us more than 256 bits of entropy. In other words I don't
think we should further complicate this and that we should stick to
entropy estimations from my current patch.
Having similar tests for different architectures would be of course very
welcome.
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://tupytaj.pl
pgpPr65nHufHL.pgp
Description: PGP signature
