[PATCH] kfence: use better stack hash seed

[Jason A. Donenfeld]

As of [1], the RNG will have incorporated both a cycle counter value and
RDRAND, in addition to various other environmental noise. Therefore,
using get_random_u32() will supply a stronger seed than simply using
random_get_entropy(). N.B.: random_get_entropy() should be considered an
internal API of random.c and not generally consumed.

[1] https://git.kernel.org/crng/random/c/c6c739b0

Cc: Alexander Potapenko <gli...@google.com>
Cc: Marco Elver <el...@google.com>
Cc: Dmitry Vyukov <dvy...@google.com>
Signed-off-by: Jason A. Donenfeld <Ja...@zx2c4.com>
---
mm/kfence/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/kfence/core.c b/mm/kfence/core.c
index c252081b11df..239b1b4b094f 100644
--- a/mm/kfence/core.c
+++ b/mm/kfence/core.c
@@ -864,7 +864,7 @@ static void kfence_init_enable(void)

void __init kfence_init(void)
{
- stack_hash_seed = (u32)random_get_entropy();
+ stack_hash_seed = get_random_u32();

/* Setting kfence_sample_interval to 0 on boot disables KFENCE. */
if (!kfence_sample_interval)
--
2.37.3

[Marco Elver]

On Mon, 26 Sept 2022 at 19:12, Jason A. Donenfeld <Ja...@zx2c4.com> wrote:
>
> As of [1], the RNG will have incorporated both a cycle counter value and
> RDRAND, in addition to various other environmental noise. Therefore,
> using get_random_u32() will supply a stronger seed than simply using
> random_get_entropy(). N.B.: random_get_entropy() should be considered an
> internal API of random.c and not generally consumed.
>
> [1] https://git.kernel.org/crng/random/c/c6c739b0
>
> Cc: Alexander Potapenko <gli...@google.com>
> Cc: Marco Elver <el...@google.com>
> Cc: Dmitry Vyukov <dvy...@google.com>
> Signed-off-by: Jason A. Donenfeld <Ja...@zx2c4.com>

Reviewed-by: Marco Elver <el...@google.com>

Assuming this patch goes after [1].

[Jason A. Donenfeld]

On Mon, Sep 26, 2022 at 7:35 PM Marco Elver <el...@google.com> wrote:
>
> On Mon, 26 Sept 2022 at 19:12, Jason A. Donenfeld <Ja...@zx2c4.com> wrote:
> >
> > As of [1], the RNG will have incorporated both a cycle counter value and
> > RDRAND, in addition to various other environmental noise. Therefore,
> > using get_random_u32() will supply a stronger seed than simply using
> > random_get_entropy(). N.B.: random_get_entropy() should be considered an
> > internal API of random.c and not generally consumed.
> >
> > [1] https://git.kernel.org/crng/random/c/c6c739b0
> >
> > Cc: Alexander Potapenko <gli...@google.com>
> > Cc: Marco Elver <el...@google.com>
> > Cc: Dmitry Vyukov <dvy...@google.com>
> > Signed-off-by: Jason A. Donenfeld <Ja...@zx2c4.com>
>
> Reviewed-by: Marco Elver <el...@google.com>
>
> Assuming this patch goes after [1].

Do you want me to queue it up in my tree to ensure that? Or would you
like to take it and just rely on me sending my PULL at the start of
the window?

Jason

[Marco Elver]

kfence patches go through -mm, so that's also a question for Andrew.

I'm guessing that your change at [1] and this patch ought to be in a
patch series together, due to that dependency. In which case it'd be
very reasonable for you to take it through your tree.

Thanks,
-- Marco

[Andrew Morton]

On Mon, 26 Sep 2022 21:31:16 +0200 Marco Elver <el...@google.com> wrote:

> On Mon, 26 Sept 2022 at 20:01, Jason A. Donenfeld <Ja...@zx2c4.com> wrote:
> >
> > On Mon, Sep 26, 2022 at 7:35 PM Marco Elver <el...@google.com> wrote:
> > >
> > > On Mon, 26 Sept 2022 at 19:12, Jason A. Donenfeld <Ja...@zx2c4.com> wrote:
> > > >
> > > > As of [1], the RNG will have incorporated both a cycle counter value and
> > > > RDRAND, in addition to various other environmental noise. Therefore,
> > > > using get_random_u32() will supply a stronger seed than simply using
> > > > random_get_entropy(). N.B.: random_get_entropy() should be considered an
> > > > internal API of random.c and not generally consumed.
> > > >
> > > > [1] https://git.kernel.org/crng/random/c/c6c739b0
> > > >
> > > > Cc: Alexander Potapenko <gli...@google.com>
> > > > Cc: Marco Elver <el...@google.com>
> > > > Cc: Dmitry Vyukov <dvy...@google.com>
> > > > Signed-off-by: Jason A. Donenfeld <Ja...@zx2c4.com>
> > >
> > > Reviewed-by: Marco Elver <el...@google.com>
> > >
> > > Assuming this patch goes after [1].
> >
> > Do you want me to queue it up in my tree to ensure that? Or would you
> > like to take it and just rely on me sending my PULL at the start of
> > the window?
>
> kfence patches go through -mm, so that's also a question for Andrew.

I can't seem to find the patch anywhere. Was I cc'ed?

Please always cc linux-kernel on patches to address this problem.
That's basically the only use for lkml nowadyas :(

> I'm guessing that your change at [1] and this patch ought to be in a
> patch series together, due to that dependency. In which case it'd be
> very reasonable for you to take it through your tree.

Yes, please keep dependents and dependees in the same series.

[Jason A. Donenfeld]

Alright, will do. I'll resend both anyway (to address some feedback on
[1]) and make a series out of them.

Jason