linux-kernel - Re: [PATCH cleanups/resubmit 0/4] Cleanups & Resubmissions for Random-dev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHmME9rW8q5dJNxG-MAxJVLK7qsN-VvVHEp7kPwbj-DtoVzeyg@mail.gmail.com>
Date:   Fri, 9 Jun 2017 02:57:31 +0200
From:   "Jason A. Donenfeld" <Jason@...c4.com>
To:     "Theodore Ts'o" <tytso@....edu>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH cleanups/resubmit 0/4] Cleanups & Resubmissions for Random-dev

Hey Ted,

On Thu, Jun 8, 2017 at 11:58 PM, Theodore Ts'o <tytso@....edu> wrote:
>>   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?

Yes, no problem, you can take the one from v5 and shuffle around the
commits. This is probably cleanest, as this is the one that should be
backported to 4.11, so it'll be more clear if it's in one commit
rather than two.

>
>>   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

Yea, they sort of did, but then they mentioned that not all devices
would actually make use of it. I was thinking that:
a) that might result in waiting when it's not necessary;
b) hci_power_on() is a bit "far" from the actual use of
get_random_bytes(), so it becomes very non-obvious and very particular
that these are related. On the otherhand, these kind of potential
non-obvious things are exactly why we've made that dmesg warning about
uninitialized randomness more clear, should it ever come up.

So, I'll send you a patch for this, and then let you decide which
approach you'd rather merge.

> 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.

Yea, that's a great idea. I might have a poke at it soon.

> 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.

Okay, that all makes sense!

Talk soon,
Jason