Hi Stephan, On Mon, 3 Aug 2020 at 16:10, Stephan Mueller <smueller@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> > wrote: > > > Eric Biggers <ebiggers@xxxxxxxxxx> 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 > >
