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=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham 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 C8259C3815B for ; Fri, 17 Apr 2020 17:19:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7EA992078E for ; Fri, 17 Apr 2020 17:19:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7EA992078E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2E2B28E003B; Fri, 17 Apr 2020 13:19:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2930E8E0023; Fri, 17 Apr 2020 13:19:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F9098E003B; Fri, 17 Apr 2020 13:19:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0192.hostedemail.com [216.40.44.192]) by kanga.kvack.org (Postfix) with ESMTP id 0A1F68E0023 for ; Fri, 17 Apr 2020 13:19:21 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id B9C1A2DFA for ; Fri, 17 Apr 2020 17:19:20 +0000 (UTC) X-FDA: 76718008080.09.knife97_8bbdd5f58e360 X-HE-Tag: knife97_8bbdd5f58e360 X-Filterd-Recvd-Size: 3351 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf47.hostedemail.com (Postfix) with ESMTP for ; Fri, 17 Apr 2020 17:19:20 +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 19711AE0D; Fri, 17 Apr 2020 17:19:18 +0000 (UTC) Subject: Re: ppc64 early slub caches have zero random value To: =?UTF-8?Q?Michal_Such=c3=a1nek?= , linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org Cc: Michael Ellerman , Kees Cook References: <20200417165304.GF25468@kitsune.suse.cz> From: Vlastimil Babka Message-ID: <8c93960b-587e-a576-91b8-666f106f8b60@suse.cz> Date: Fri, 17 Apr 2020 19:19:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200417165304.GF25468@kitsune.suse.cz> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US 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: On 4/17/20 6:53 PM, Michal Such=E1nek 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, = slab_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->ran= dom); > #endif > =20 > if (!calculate_sizes(s, -1)) >=20 > I get: >=20 > [ 0.000000] random: get_random_u64 called from kmem_cache_open+0x3c/= 0x5b0 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-68253214732= 3126958 >=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 randomize= d > 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 thi= s > ever worked. All examples of earlier kernels I have at hand use slab mm= . >=20 > Thanks >=20 > Michal >=20