linux-kernel - Re: [RFC PATCH v12 2/4] random: conditionally compile code depending on LRNG

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] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 18 Jul 2017 10:50:10 +0200
From:   Stephan Müller <smueller@...onox.de>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     "Jason A. Donenfeld" <jason@...c4.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-crypto@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH v12 2/4] random: conditionally compile code depending on LRNG

Am Dienstag, 18. Juli 2017, 10:47:00 CEST schrieb Arnd Bergmann:

Hi Arnd,

> On Tue, Jul 18, 2017 at 10:37 AM, Stephan Müller <smueller@...onox.de> 
wrote:
> > Am Dienstag, 18. Juli 2017, 10:13:55 CEST schrieb Arnd Bergmann:
> >> On Tue, Jul 18, 2017 at 9:58 AM, Stephan Müller <smueller@...onox.de> 
wrote:
> >> > When selecting the LRNG for compilation, disable add_disk_randomness
> >> > and
> >> > its supporting function.
> >> > 
> >> > CC: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> >> > CC: Arnd Bergmann <arnd@...db.de>
> >> > CC: Jason A. Donenfeld <Jason@...c4.com>
> >> > Signed-off-by: Stephan Mueller <smueller@...onox.de>
> >> 
> >> I think this needs a better explanation. Why do we ignore the extra
> >> entropy here?
> > 
> > I was not sure whether to add all the details about the reason into the
> > patch submission.
> > 
> > The reason is explained here in [1] page 3 and re-iterated in [2].
> 
> Ok, got it. A half-sentence summary of that ("... to avoid adding the
> same event twice from interrupt and block") would be sufficient for
> the patch description, longer is also fine.

Perfect, thank you for that hint. I will add this information to a next 
iteration.
> 
> Generally speaking, each patch description should describe why
> that particular patch is required rather than describe what it does
> (which in cases like this is plain to see from looking a few lines
> down).
> 
>         Arnd



Ciao
Stephan