On Thu, 23 Sep 2021 15:44:10 +0200 Marco Elver <elver@xxxxxxxxxx> 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?
