Re: ppc64 early slub caches have zero random value
From: Vlastimil Babka <hidden>
Date: 2020-04-17 17:19:21
Also in:
linux-mm
On 4/17/20 6:53 PM, Michal Suchánek wrote:
Hello,
Hi, thanks for reproducing on latest upstream!
quoted hunk ↗ jump to hunk
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