Q for a new API for the random device driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Theodore, hi Linux Community

my patch for the s390 arch_get_random_seed* implementation is about to
be integrated with the current merge window for kernel 4.18.

So I'd like to start a discussion about a new API for the random.c
device driver. The current s390 hardware comes with a true hardware
random generator. This great random source provides high quality
entropy (100% according to our hardware guys) but is relatively slow.

I want to provide this entropy source to the random pool of the
random device driver. The only possibility is the implementation of
the arch_get_random* and arch_get_random_seed* API. So my first attempt
was to implement the arch_get_random* functions and directly call the
TRNG. This code made it into the 4.12 kernel and slowed down the
/dev/urandom performance remarkable. So the first rework removed the
s390 arch_get_random* implementation and instead provided the
arch_*_seed functions. The idea was that your good but slow TRNG is
ideal for providing entropy as seed for pseudo random
generators. However, as arch_get_random_seed_long() is called very
frequently in interrupt context and this limits the amount of irqs
per cpu remarkable (e.g. on heavy network load). As a result my latest
fix introduces some kind of buffer concept in combination with filling
the buffer asynchronous with a cascaded TRNG/PRNG.

I am still searching for a way to provide our good hardware entropy
source to the random pool in the random device driver. So I'd like to
have a new arch interface which is called when the random pool finds
out that it is running out of entropy. My feeling is that it should
not be the only source but should still be mixed with other sources
of entropy. It should not be able to dominate or occupy the random
pool but contribute to a significant part.

As nowadays true random generators provide conditioned data usually
with some kind of hashing algorithm a granularity of 4 or 8 bytes is
waste of random entropy. The s390 TRNG uses SHA512 and can provide
64 bytes entropy with each invocation. Other TRNGs may use sha1 or
sha256 and so provide 20 or 32 bytes of random. However, the API
could be something like:

  int arch_get_entropy(void *buf, int bufsize);

and the function returns:

  < 0 - error, negative errno value
  0...bufsize - amount of entropy bytes written into the buffer
        may be 0 if there is (currently) no random entropy
        available. No need to fill the buffer, any data in the
        range of 0 up to bufsize is welcome.

random.c could call this api with a buffer of 64 bytes when the
computed entropy within the pool drops below a threshold limit.

The call should not be done within a userspace process context or
'foreign' kernel context (like irqs) but with an own kernel thread
or workqueue or similar. The data returned should be mixed into
the pool and counted as entropy.

I think, other architectures could also benefit from such a new
interface. Power and even x86 have or will have true random entropy
source hardware and may also like to contribute to the linux random
device driver.

Does this sound reasonable? If yes, I'll start some investigation and
try to develop something for random.c. Though this may take some time.

regards and thanks for your time
Harald Freudenberger




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux