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;
From:   Stephan Mueller <smueller@chronox.de>
To:     Herbert Xu <herbert@gondor.apana.org.au>,
        Elena Petrova <lenaptr@google.com>
Cc:     "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>
Subject: Re: [PATCH v4] crypto: af_alg - add extra parameters for DRBG interface
Date:   Mon, 03 Aug 2020 17:10:03 +0200
Message-ID: <4818892.iTQEcLzFEP@tauon.chronox.de>
In-Reply-To: <CABvBcwY-F6Euo2SAY6MKpT0KP7OtyswLhUmShPNPfB0qqL6heQ@mail.gmail.com>
References: <20200729154501.2461888-1-lenaptr@google.com> <20200731072338.GA17285@gondor.apana.org.au> <CABvBcwY-F6Euo2SAY6MKpT0KP7OtyswLhUmShPNPfB0qqL6heQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

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.

Ciao
Stephan