Message-ID: <20170608215821.s5w5dtgpts3p6w7x@thunk.org>
Date:   Thu, 8 Jun 2017 17:58:22 -0400
From:   Theodore Ts'o <tytso@....edu>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH cleanups/resubmit 0/4] Cleanups & Resubmissions for
 Random-dev

On Thu, Jun 08, 2017 at 02:29:28PM +0200, Jason A. Donenfeld wrote:
> Hi Ted,
> 
> I'm not super sure what your workflow is like, but yesterday you picked
> up my v4 instead of my v5

I use offlineimap to sync my Inbox to my laptop, and so while I was
working on reviewing and applying your v4 patches, your v5 patches
went out.  These things happen.  No big deal.

The random.git tree is one where no one else is depending on my tree,
so I don't mind making rewinding the branch head to update patches.  I
don't do this with fcrypt.git, although I do this for the ext4.git
tree.  Since there are other file system trees that build on top of,
or pull in fscrypt.git, I won't rewinding the branch since that causes
them pain.  But that's not real issue for ext4.git and random.git
since it gets incorporated into linux-next (which is also rewound
every day), but not any other subsystem tree.  In the rare case where
someone needs to do that, I'll use the "master" branch to denote that
this is a branch that I won't rewind.

>   security/keys: ensure RNG is seeded before use
> 
> You had noticed an issue with this in v4/v5, so now this is cleaned up
> the way you suggested so that you can merge it.

Thanks!

> 
>   random: squelch sh compiler warning and ensure safe optimization
> 
> This was the biggie -- I had incorporated this fix into v5, but you picked
> up v4, so this commit is an additional one to bring your tree up to date,
> without having to rebase or rewrite history.

Or I can just grab the updated commit from v5, yes?

>   bluetooth/smp: ensure RNG is properly seeded before ECDH use
> 
> This one is pending your approval from the bluetooth people.

I think they said it would be enough to add wait_for_random_bytes()
to the hci_power_on function

We probably should ask them to send us a patch that exposes the
hardware RNG in the Bluetooth LE devices.  Anytime we can get more
entropy, I want to mix it into the entropy pools, even if we don't
give any entropy credit.

Anything to make the government cryptographers work for a living.  :-)

> 
>   crypto/rng: ensure that the RNG is ready before using
> 
> This one I assume you didn't pick up because it depends on my big_keys
> rewrite going through.

Yes; depending on when it goes through (e.g., if it's the next merge
window) we can just also run it through the crypto tree.  The main
reason I'm running some of these changes through the random.git tree
is because they have a dependency on the new interfaces that you've
introduced.  As we play whack-a-mole with all of the vairous
get_random_byte users, we can either run them through their tree, or
if the code in doesn't doesn't an active maintainer, or the maintainer
prefers that we run them through random.git, we can run them through
random.git tree.

> Sorry for the procedural back-and-forth. If there's a way to do this flow
> better next time, do tell me what it is. Alternatively, if you're ever on
> IRC, realtime chat could be useful.

These days I'm generally too busy to be on IRC.  If there's something
really urgent you can try hitting me up on Google Hangouts, or
schedule a Google Video Chat if it really needs face-to-face
communications.

I'm often travelling or time sharing between multiple projects, so do
understand that sometimes my delay in responding is because I'm busy
or because I'm deliberately waiting for other people to do review the
patches before I do a detailed review.  

						- Ted

Powered by blists - more mailing lists