On Thu, Oct 10, 2013 at 08:08:41AM -0700, H. Peter Anvin wrote:
>
> Mainly the maintainer isn't merging in fixes from upstream, apparently
> because he has misunderstood their function.
>From the README file from the Debian fork:
rng-tools unofficial-mt is a living reminder to myself to not modify upstream
code without sending the changes upstream at every step. Suddenly, you have a
mass of changes too big to send upstream, and yet you find yourself without the
energy to break them into smallish patches to submit upstream (i.e. to
"unfork").
> > What I'm trying to say with all this is that self-tests must be
> > customized for each entropy source.
>
> Yes. I don't think the FIPS tests make any sense at all (up to and
> including rngd 3 they would eventually kill rngd, because it only
> allowed for a fixed number of false positives.)
... and to the extent that output is crypto-whitened in the hardware,
with no way of disabling the whitening, it's actually kind of hopeless
to do any kind of testing.
One of the reasons why I wanted to keep this functionality in
userspace, as opposed to moving this into a kernel thread, is because
I was hoping someone would create hardware which did not do hardware
whitening, and userspace could do proper quality checking of the
entropy source, and data reduction as necessary, all in the an open
and auditable way. If we are doing the those more heavyweight tests,
it's not a clear it makes sense to put all of this in the kernel.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
