From: Nicolai Stange <nstange@suse.de>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: "Michal Suchánek" <msuchanek@suse.de>,
linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Kees Cook" <keescook@chromium.org>,
"Theodore Ts'o" <tytso@mit.edu>,
"Jason A. Donenfeld" <Jason@zx2c4.com>,
"Andy Lutomirski" <luto@kernel.org>,
linux-kernel@vger.kernel.org
Subject: Re: ppc64 early slub caches have zero random value
Date: Tue, 21 Apr 2020 10:39:27 +0200 [thread overview]
Message-ID: <871rohz0zk.fsf@suse.de> (raw)
In-Reply-To: <8c93960b-587e-a576-91b8-666f106f8b60@suse.cz> (Vlastimil Babka's message of "Fri, 17 Apr 2020 19:19:17 +0200")
Hi
[adding some drivers/char/random folks + LKML to CC]
Vlastimil Babka <vbabka@suse.cz> writes:
> On 4/17/20 6:53 PM, Michal Suchánek wrote:
>> Hello,
>
> Hi, thanks for reproducing on latest upstream!
>
>> instrumenting the kernel with the following patch
>>
>> ---
>> mm/slub.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/mm/slub.c b/mm/slub.c
>> index d6787bbe0248..d40995d5f8ff 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -3633,6 +3633,7 @@ static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
>> s->flags = kmem_cache_flags(s->size, flags, s->name, s->ctor);
>> #ifdef CONFIG_SLAB_FREELIST_HARDENED
>> s->random = get_random_long();
>> + pr_notice("Creating cache %s with s->random=%ld\n", s->name, s->random);
>> #endif
>>
>> if (!calculate_sizes(s, -1))
>>
>> I get:
>>
>> [ 0.000000] random: get_random_u64 called from kmem_cache_open+0x3c/0x5b0
> with crng_init=0
>> [ 0.000000] Creating cache kmem_cache_node with s->random=0
>> [ 0.000000] Creating cache kmem_cache with s->random=0
>> [ 0.000000] Creating cache kmalloc-8 with s->random=0
>> [ 0.000000] Creating cache kmalloc-16 with s->random=0
>> [ 0.000000] Creating cache kmalloc-32 with s->random=0
>> [ 0.000000] Creating cache kmalloc-64 with s->random=0
>> [ 0.000000] Creating cache kmalloc-96 with s->random=0
>> [ 0.000000] Creating cache kmalloc-128 with s->random=0
>> [ 0.000000] Creating cache kmalloc-192 with s->random=-682532147323126958
>>
>> The earliest caches created invariably end up with s->random of zero.
>
> It seems that reliably it's the first 8 calls get_random_u64(), which sounds
> more like some off-by-X bug than a genuine lack entropy that would become fixed
> in the meanwhile?
>
>> This is a problem for crash which does not recognize these as randomized
>> and fails to read them. While this can be addressed in crash is it
>> intended to create caches with zero random value in the kernel?
>
> Definitely not. The question is more likely what guarantees we have with
> crng_init=0. Probably we can't expect cryptographically strong randomness, but
> zeroes still do look like a bug to me?
>
>> This is broken at least in the 5.4~5.7 range but it is not clear if this
>> ever worked. All examples of earlier kernels I have at hand use slab mm.
>>
>> Thanks
>>
>> Michal
>>
FWIW, I've seen something similar in a slightly different context,
c.f. [1].
Basically, the issue is that on anything but x86_64 (and perhaps arm64
IIRC), arch_get_random_long() is unavailable and thus, get_random_u64()
falls through to that batched extract_crng() extraction. That is, it
extracts eight random longs from the chacha20 based RNG at once and
batches them up for consumption by the current and subsequent
get_random_u64() invocations. Which is in line with your observation
that get_random_u64() returned zero exactly eight times in a row.
The fact that extract_crng() actually extracted eight successive zero
values surprised me though. But from looking at chacha20_block(), called
from _extract_crng() with the primary_crng instance's state buffer as
input, it seems like a zeroed state buffer gets identity transformed and
that all this fancy shifting and rolling and whatnot in chacha_permute()
would have no effect at all. So I suppose that the primary_crng's state
buffer is still zeroed out at that point during boot.
Thanks,
Nicolai
[1] https://lkml.kernel.org/r/87d08rbbg9.fsf@suse.de
--
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg), GF: Felix Imendörffer
next prev parent reply other threads:[~2020-04-21 8:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-17 16:53 ppc64 early slub caches have zero random value Michal Suchánek
2020-04-17 17:19 ` Vlastimil Babka
2020-04-21 8:39 ` Nicolai Stange [this message]
2020-04-22 11:13 ` Vlastimil Babka
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=871rohz0zk.fsf@suse.de \
--to=nstange@suse.de \
--cc=Jason@zx2c4.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=msuchanek@suse.de \
--cc=tytso@mit.edu \
--cc=vbabka@suse.cz \
/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).