From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6ACB5C2BA19 for ; Tue, 21 Apr 2020 08:39:33 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 36B852098B for ; Tue, 21 Apr 2020 08:39:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 36B852098B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E17558E0005; Tue, 21 Apr 2020 04:39:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DC9A08E0003; Tue, 21 Apr 2020 04:39:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB69A8E0005; Tue, 21 Apr 2020 04:39:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0057.hostedemail.com [216.40.44.57]) by kanga.kvack.org (Postfix) with ESMTP id B1FD58E0003 for ; Tue, 21 Apr 2020 04:39:31 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6AD3B181AEF1D for ; Tue, 21 Apr 2020 08:39:31 +0000 (UTC) X-FDA: 76731213342.11.mom62_35f9d0b25162e X-HE-Tag: mom62_35f9d0b25162e X-Filterd-Recvd-Size: 5116 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Tue, 21 Apr 2020 08:39:30 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 3700EADCD; Tue, 21 Apr 2020 08:39:28 +0000 (UTC) From: Nicolai Stange To: Vlastimil Babka Cc: Michal =?utf-8?Q?Such=C3=A1nek?= , linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, Michael Ellerman , Kees Cook , "Theodore Ts'o" , Jason A. Donenfeld , Andy Lutomirski , linux-kernel@vger.kernel.org Subject: Re: ppc64 early slub caches have zero random value References: <20200417165304.GF25468@kitsune.suse.cz> <8c93960b-587e-a576-91b8-666f106f8b60@suse.cz> Date: Tue, 21 Apr 2020 10:39:27 +0200 In-Reply-To: <8c93960b-587e-a576-91b8-666f106f8b60@suse.cz> (Vlastimil Babka's message of "Fri, 17 Apr 2020 19:19:17 +0200") Message-ID: <871rohz0zk.fsf@suse.de> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi [adding some drivers/char/random folks + LKML to CC] Vlastimil Babka writes: > On 4/17/20 6:53 PM, Michal Such=C3=A1nek wrote: >> Hello, > > Hi, thanks for reproducing on latest upstream! > >> instrumenting the kernel with the following patch >>=20 >> --- >> mm/slub.c | 1 + >> 1 file changed, 1 insertion(+) >>=20 >> 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, s= lab_flags_t flags) >> s->flags =3D kmem_cache_flags(s->size, flags, s->name, s->ctor); >> #ifdef CONFIG_SLAB_FREELIST_HARDENED >> s->random =3D get_random_long(); >> + pr_notice("Creating cache %s with s->random=3D%ld\n", s->name, s->rand= om); >> #endif >>=20=20 >> if (!calculate_sizes(s, -1)) >>=20 >> I get: >>=20 >> [ 0.000000] random: get_random_u64 called from kmem_cache_open+0x3c/0= x5b0 > with crng_init=3D0 >> [ 0.000000] Creating cache kmem_cache_node with s->random=3D0 >> [ 0.000000] Creating cache kmem_cache with s->random=3D0 >> [ 0.000000] Creating cache kmalloc-8 with s->random=3D0 >> [ 0.000000] Creating cache kmalloc-16 with s->random=3D0 >> [ 0.000000] Creating cache kmalloc-32 with s->random=3D0 >> [ 0.000000] Creating cache kmalloc-64 with s->random=3D0 >> [ 0.000000] Creating cache kmalloc-96 with s->random=3D0 >> [ 0.000000] Creating cache kmalloc-128 with s->random=3D0 >> [ 0.000000] Creating cache kmalloc-192 with s->random=3D-682532147323= 126958 >>=20 >> 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 sou= nds > 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=3D0. Probably we can't expect cryptographically strong randomne= ss, 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. >>=20 >> Thanks >>=20 >> 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 --=20 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, G= ermany (HRB 36809, AG N=C3=BCrnberg), GF: Felix Imend=C3=B6rffer