netdev - Re: [PATCH net-next] random32: improvements to prandom

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Sun, 24 Aug 2014 18:36:26 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	dborkman@...hat.com
Cc:	akinobu.mita@...il.com, LW@...O-electronics.de,
	netdev@...r.kernel.org, hannes@...essinduktion.org
Subject: Re: [PATCH net-next] random32: improvements to prandom_bytes

From: Daniel Borkmann <dborkman@...hat.com>
Date: Sat, 23 Aug 2014 17:03:28 +0200

> 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,
> drivers/mtd/tests/{oobtest.c,pagetest.c,subpagetest.c}:
> 
> 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: Daniel Borkmann <dborkman@...hat.com>
> Tested-by: Akinobu Mita <akinobu.mita@...il.com>
> Tested-by: Lothar Waßmann <LW@...O-electronics.de>
> Cc: Hannes Frederic Sowa <hannes@...essinduktion.org>

Applied, thanks Daniel.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html