Well, adding non-random stuff to /dev/random's entropy pool won't decrease the
randomness of its output, but it may throw off its estimate of the available
entropy. Even if someone does manage to get the i810 to generate
non-randomness, they still need to break /dev/random's bit-mixer to determine
the internal state to be able to predict its output.
I think having it inject randomness into the /dev/random pool directly (ie
without a user-mode component) seems like the cleanest solution.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/