Bug#662736: Some concerns about adding maxwell to Debian
I am somewhat worried about this package being added to Debian.
The kernel itself is responsible for collecting randomness from interrupts
when it is deemed safe enough, this is NOT a task well suited to userspace.
Userspace should gather entropy from external sources (like audio noise, USB
HRNGs, or an entropy data feed over the network).
Timer interrupts are the most dangerous of them all for entropy gathering:
there are strong correlations between the userspace process scheduler and
timer interrupts and the kernel timers/clocks, the NOHZ tickless mode
interferes with it, and any hypervisor/VM environment will interfere a lot
with timekeeping as well. Both light loads and heavy loads may cause timer
jitter to have a lot less noise than expected.
One would need to have statistically significant proof that the operations
implemented by the maxwell daemon are indeed enough to provide the expected
entropy on a variety of scenarios that are relevant to the timers and to the
process scheduler, *using the Debian kernel targetted for release*, on every
arch it is going to be available for. This does not seem feasible.
Also, the BIAS on anything related to interfering with the system RNG must
be on security, and not on "small fast program".
I don't think we should accept this package in Debian as-is.
I recommend it to be restricted to archs where it was tested, which is
x86-64 right now (more can be added if either the maintainer or upstream
does the required testing using diehard). I also recommend that at least
the high syscall load be addressed upstream first (batch several seconds
worth of entropy, and feed it in just one ioctl syscall to the kernel). It
would also be advisable to ship it configured by default in Debian to credit
at most 50%-70% of entropy, so as to account for unexpected behaviour on the
process cheduler and system timers.
I'd also recommend that it be tested first in a VM environment, using
maxwell -t inside a VM to generate the required (gigabytes) of data to a
file (lightly-loaded VM), and then to run diehard on the result. The test
with a heavy-loaded VM can be done by just running maxwell and diehard in a
pipe configuration inside the same VM.
Initial entropy at very early boot, before Debian seeds the kernel, is a
task that can only be done properly by the kernel itself, and is being
addressed there at this time (patches have already been proposed). The
proper fix for better initial entropy at boot is to backport these changes
to the Debian kernel. I do not consider maxwell relevant for this scenario.
For other entropy gathering needs, there are safer choices. This should be
reflected on the package description.
Another concern is that maxwell looks like an academic work from upstream,
it would be best to talk to upstream to check their medium and long-term
plans for maintaining maxwell, etc. before we commit to shipping maxwell in
Debian stable. As long as it is not shipped in Wheezy, this is not an
immediate or very pressing concern, as it is relatively harmless to remove
packages that are present only on testing and unstable, and never made it to
a stable Debian release.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: