From: Elena Petrova <lenaptr@google.com>
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>
Subject: Re: [PATCH v4] crypto: af_alg - add extra parameters for DRBG interface
Date: Mon, 3 Aug 2020 16:30:21 +0100 [thread overview]
Message-ID: <CABvBcwaV0FdSeEz1ddW3yGwcbOOOVy-3jL32futGrtDWc506vg@mail.gmail.com> (raw)
In-Reply-To: <4818892.iTQEcLzFEP@tauon.chronox.de>
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
>
>
next prev parent reply other threads:[~2020-08-03 15:30 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-13 16:48 [PATCH 0/1] crypto: af_alg - add extra parameters for DRBG interface Elena Petrova
2020-07-13 16:48 ` [PATCH 1/1] " Elena Petrova
2020-07-13 17:10 ` Eric Biggers
2020-07-16 14:23 ` Elena Petrova
2020-07-16 16:40 ` [PATCH v2] " Elena Petrova
2020-07-20 17:35 ` Stephan Mueller
2020-07-21 12:55 ` Elena Petrova
2020-07-21 13:18 ` Stephan Mueller
2020-07-28 16:16 ` Elena Petrova
2020-07-20 17:42 ` Stephan Müller
2020-07-22 15:59 ` Eric Biggers
2020-07-28 15:51 ` [PATCH v3] " Elena Petrova
2020-07-28 17:36 ` Eric Biggers
2020-07-29 15:45 ` [PATCH v4] " Elena Petrova
2020-07-29 19:26 ` Stephan Müller
2020-07-31 7:23 ` Herbert Xu
2020-08-03 14:48 ` Elena Petrova
2020-08-03 15:10 ` Stephan Mueller
2020-08-03 15:30 ` Elena Petrova [this message]
2020-08-04 2:18 ` Herbert Xu
2020-07-13 17:25 ` [PATCH 1/1] " Eric Biggers
2020-07-31 7:26 ` Herbert Xu
2020-08-13 16:00 ` Elena Petrova
2020-08-13 16:01 ` [PATCH v4] " Elena Petrova
2020-08-13 16:04 ` Elena Petrova
2020-08-13 16:08 ` [PATCH v5] " Elena Petrova
2020-08-13 19:32 ` Eric Biggers
2020-08-21 4:24 ` Herbert Xu
2020-09-08 17:04 ` [PATCH v6] " Elena Petrova
2020-09-09 4:35 ` Eric Biggers
2020-09-09 18:29 ` [PATCH v7] " Elena Petrova
2020-09-09 21:00 ` Eric Biggers
2020-09-16 11:07 ` [PATCH v8] " Elena Petrova
2020-09-18 6:43 ` Herbert Xu
2020-09-18 15:42 ` [PATCH v9] " Elena Petrova
2020-09-25 8:16 ` Herbert Xu
2020-09-08 17:23 ` [PATCH v5] " Elena Petrova
2020-09-08 17:18 ` Elena Petrova
2020-07-14 5:17 ` [PATCH 0/1] " Stephan Mueller
2020-07-14 15:23 ` Elena Petrova
2020-07-14 15:34 ` Stephan Mueller
2020-07-16 14:41 ` Elena Petrova
2020-07-16 14:49 ` Stephan Mueller
2020-07-16 14:59 ` Stephan Mueller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABvBcwaV0FdSeEz1ddW3yGwcbOOOVy-3jL32futGrtDWc506vg@mail.gmail.com \
--to=lenaptr@google.com \
--cc=ardb@kernel.org \
--cc=ebiggers@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=jeffv@google.com \
--cc=linux-crypto@vger.kernel.org \
--cc=smueller@chronox.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).