Bug#662736: Some concerns about adding maxwell to Debian
On 12-07-20 10:11 AM, Henrique de Moraes Holschuh wrote:
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.
Labeling the algorithm as "good" or "bad" is going to be context
sensitive. Small embedded systems with no network activity, such us
monitors or autonomous process controllers, might benefit from a
timer-based entropy generator for example. In any case, I don't believe
that it is up to the Debian distribution to determine in advance whether
a package is good or bad for a system; as with any other package, this
decision ultimately belongs to the system designer or administrator who
knows what he wants to achieve. We have to provide the package in the
first place, ensure that it is run with safe default values, and that it
is properly documented so that some one else can make a final educated
decision on the program's fit for a particular application.
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 do agree in that if Maxwell is to be introduced it has to be done on
an arch by arch basis as the program testing plan goes. At this moment
it has only been tested on the x86-64. As a potential maintainer for
this program I can say that I have the capability to also test it on x86
and soon in ARM archs.
Your recommendations are worth noticing and will certainly be considered
as the maintenance and packaging exercise move along. I just did a first
round of packaging to get things started but there is certainly much
more work yet to be done.
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.
Agree, as I mentioned before, work on documentation is needed to ensure
that we provide enough information for the system designer/administrator
to make informed decision about how to use or not to use maxwell.
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.
I do share this concern as well. I invite the upstream maintainer to let
us know about his plans and what we can expect as support from him in
the short and long terms. I added him to the CC of this e-mail just in
case he is not monitoring the #662736.
Thank you for your comments and interest in this package.
--
Pedro I. Sanchez
Reply to: