• Daniel Borkmann's avatar
    random32: improvements to prandom_bytes · a98406e2
    Daniel Borkmann authored
    This patch addresses a couple of minor items, mostly addesssing
    prandom_bytes(): 1) prandom_bytes{,_state}() should use size_t
    for length arguments, 2) We can use put_unaligned() when filling
    the array instead of open coding it [ perhaps some archs will
    further benefit from their own arch specific implementation when
    GCC cannot make up for it ], 3) Fix a typo, 4) Better use unsigned
    int as type for getting the arch seed, 5) Make use of
    prandom_u32_max() for timer slack.
    Regarding the change to put_unaligned(), callers of prandom_bytes()
    which internally invoke prandom_bytes_state(), don't bother as
    they expect the array to be filled randomly and don't have any
    control of the internal state what-so-ever (that's also why we
    have periodic reseeding there, etc), so they really don't care.
    Now for the direct callers of prandom_bytes_state(), which
    are solely located in test cases for MTD devices, that is,
    These tests basically fill a test write-vector through
    prandom_bytes_state() with an a-priori defined seed each time
    and write that to a MTD device. Later on, they set up a read-vector
    and read back that blocks from the device. So in the verification
    phase, the write-vector is being re-setup [ so same seed and
    prandom_bytes_state() called ], and then memcmp()'ed against the
    read-vector to check if the data is the same.
    Akinobu, Lothar and I also tested this patch and it runs through
    the 3 relevant MTD test cases w/o any errors on the nandsim device
    (simulator for MTD devs) for x86_64, ppc64, ARM (i.MX28, i.MX53
    and i.MX6):
      # modprobe nandsim first_id_byte=0x20 second_id_byte=0xac \
                         third_id_byte=0x00 fourth_id_byte=0x15
      # modprobe mtd_oobtest dev=0
      # modprobe mtd_pagetest dev=0
      # modprobe mtd_subpagetest dev=0
    We also don't have any users depending directly on a particular
    result of the PRNG (except the PRNG self-test itself), and that's
    just fine as it e.g. allowed us easily to do things like upgrading
    from taus88 to taus113.
    Signed-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
    Tested-by: default avatarAkinobu Mita <akinobu.mita@gmail.com>
    Tested-by: default avatarLothar Waßmann <LW@KARO-electronics.de>
    Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
random32.c 12.6 KB