Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200729154501.2461888-1-lenaptr@google.com> <20200731072338.GA17285@gondor.apana.org.au>
 <CABvBcwY-F6Euo2SAY6MKpT0KP7OtyswLhUmShPNPfB0qqL6heQ@mail.gmail.com> <4818892.iTQEcLzFEP@tauon.chronox.de>
In-Reply-To: <4818892.iTQEcLzFEP@tauon.chronox.de>
From:   Elena Petrova <lenaptr@google.com>
Date:   Mon, 3 Aug 2020 16:30:21 +0100
Message-ID: <CABvBcwaV0FdSeEz1ddW3yGwcbOOOVy-3jL32futGrtDWc506vg@mail.gmail.com>
Subject: Re: [PATCH v4] crypto: af_alg - add extra parameters for DRBG interface
To:     Stephan Mueller <smueller@chronox.de>
Cc:     Herbert Xu <herbert@gondor.apana.org.au>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@vger.kernel.org>, Eric Biggers <ebiggers@kernel.org>,
        Ard Biesheuvel <ardb@kernel.org>,
        Jeffrey Vander Stoep <jeffv@google.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

Hi Stephan,

On Mon, 3 Aug 2020 at 16:10, Stephan Mueller <smueller@chronox.de> wrote:
>
> Am Montag, 3. August 2020, 16:48:02 CEST schrieb Elena Petrova:
>
> Hi Elena,
>
> > On Fri, 31 Jul 2020 at 08:27, Herbert Xu <herbert@gondor.apana.org.au>
> wrote:
> > > Eric Biggers <ebiggers@kernel.org> wrote:
> > > > lock_sock() would solve the former.  I'm not sure what should be done
> > > > about
> > > > rng_recvmsg().  It apparently relies on the crypto_rng doing its own
> > > > locking, but maybe it should just use lock_sock() too.
> > >
> > > The lock_sock is only needed if you're doing testing.  What I'd
> > > prefer is to have a completely different code-path for testing.
> >
> > sendmsg is used for "Additional Data" input, and unlike entropy, it
> > could be useful outside of testing. But if you confirm it's not
> > useful, then yes, I can decouple the testing parts.
>
> Nobody has requested it for now - so why not only compiling it when the DRBG
> test config value is set? If for some reason there is a request to allow
> setting the additional data from user space, we may simply take the ifdef
> away.
>
> My approach is to have only interfaces into the kernel that are truly
> requested and needed.

Ok, makes sense, thanks!

> Ciao
> Stephan
>
>