[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHmME9oGBpm=nBuDnSoVBg1A9BMvmR_9EpWE9nH6xoJONZv_fQ@mail.gmail.com>
Date: Thu, 8 Jun 2017 03:03:38 +0200
From: "Jason A. Donenfeld" <Jason@...c4.com>
To: "Theodore Ts'o" <tytso@....edu>, "Jason A. Donenfeld" <Jason@...c4.com>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
kernel-hardening@...ts.openwall.com,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, David Miller <davem@...emloft.net>,
Eric Biggers <ebiggers3@...il.com>, David Howells <dhowells@...hat.com>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>, David Safford <safford@...ibm.com>
Subject: Re: [PATCH v4 04/13] security/keys: ensure RNG is seeded before use
On Thu, Jun 8, 2017 at 2:50 AM, Jason A. Donenfeld <Jason@...c4.com> wrote:
> On Thu, Jun 8, 2017 at 2:31 AM, Theodore Ts'o <tytso@....edu> wrote:
>> I'm guessing you changed key_alloc_serial() to return an int back when
>> you were thinking that you might use get_random_bytes_wait(), which
>> could return -ERESTARTSYS.
>>
>> Now that you're not doing this, but using get_random_u32() instead,
>> there's no point to change the function signature of
>> key_alloc_serial() and add an error check in key_alloc() that will
>> never fail, right? That's just adding a dead code path. Which the
>> compiler can probably optimize away, but why make the code slightly
>> harder to read than necessasry?
>
> Good catch, and thanks for reading these so thoroughly that you caught
> the churn artifacts. Do you want me to clean this up and resubmit, or
> are you planning on adjusting it in the dev branch?
Fixed it up here if you just want to grab this instead:
https://git.kernel.org/pub/scm/linux/kernel/git/zx2c4/linux.git/patch/?id=a0361e55bce30ace529ed8b28bd452e3ac0ee91f
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
