lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 23 Sep 2021 16:28:11 -0700 From: Andrew Morton <akpm@...ux-foundation.org> To: Marco Elver <elver@...gle.com> Cc: Alexander Potapenko <glider@...gle.com>, Dmitry Vyukov <dvyukov@...gle.com>, Jann Horn <jannh@...gle.com>, Aleksandr Nogikh <nogikh@...gle.com>, Taras Madan <tarasmadan@...gle.com>, LKML <linux-kernel@...r.kernel.org>, Linux Memory Management List <linux-mm@...ck.org>, kasan-dev <kasan-dev@...glegroups.com> Subject: Re: [PATCH v3 4/5] kfence: limit currently covered allocations when pool nearly full On Thu, 23 Sep 2021 15:44:10 +0200 Marco Elver <elver@...gle.com> wrote: > > > > + * time, the below parameters provide a probablity of 0.02-0.33 for false > > > > + * positive hits respectively: > > > > + * > > > > + * P(alloc_traces) = (1 - e^(-HNUM * (alloc_traces / SIZE)) ^ HNUM > > > > + */ > > > > +#define ALLOC_COVERED_HNUM 2 > > > > +#define ALLOC_COVERED_SIZE (1 << (const_ilog2(CONFIG_KFENCE_NUM_OBJECTS) + 2)) > > > > +#define ALLOC_COVERED_HNEXT(h) (1664525 * (h) + 1013904223) > > > > Unless we are planning to change these primes, can you use > > next_pseudo_random32() instead? > > I'm worried about next_pseudo_random32() changing their implementation > to longer be deterministic or change in other ways that break our > usecase. In this case we want pseudorandomness, but we're not > implementing a PRNG. > > Open-coding the constants (given they are from "Numerical Recipes") is > more reliable and doesn't introduce unwanted reliance on > next_pseudo_random32()'s behaviour. Perhaps we could summarize this in an additional comment? Also, this: +static u32 get_alloc_stack_hash(unsigned long *stack_entries, size_t num_entries) +{ + /* Some randomness across reboots / different machines. */ + u32 seed = (u32)((unsigned long)__kfence_pool >> (BITS_PER_LONG - 32)); seems a bit weak. Would it be better to seed this at boot time with a randomish number?
Powered by blists - more mailing lists