linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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


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