[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGXu5jKj=SfzZqiPtRir7ombU7cLd=sD0e2ehoY=4+y7pZjyjA@mail.gmail.com>
Date: Tue, 16 Apr 2019 17:58:56 -0500
From: Kees Cook <keescook@...gle.com>
To: Daniel Borkmann <daniel@...earbox.net>
Cc: Hannes Frederic Sowa <hannes@...essinduktion.org>,
LKML <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
"Reshetova, Elena" <elena.reshetova@...el.com>,
Alexei Starovoitov <ast@...nel.org>
Subject: Re: BPF RNG
On Tue, Apr 16, 2019 at 10:13 AM Daniel Borkmann <daniel@...earbox.net> wrote:
>
> On 04/16/2019 03:55 PM, Kees Cook wrote:
> > [correcting Alexei's email address and resending...]
> >
> > On Tue, Apr 16, 2019 at 8:54 AM Kees Cook <keescook@...gle.com> wrote:
> >>
> >> Hi,
> >>
> >> In looking at prandom_u32() users, I noticed that BPF uses its own
> >> state variable with bpf_user_rnd_u32(). It appears that this state is
>
> Correct, we split that off from the main one.
>
> >> never reseeded like regular prandom_u32(). (See __prandom_timer().) Is
> >> this intentional, or should reseeding be happening?
>
> The prng is not to be used in any security-critical context. That said,
> we optionally could perform reseeding from time to time, though that
> should probably be done generically, so that all "external"
> prandom_u32_state() users could register themselves upon init whether
> they opt-in for periodic reseeding or not.
Yeah, it seemed like it should be built into the API. I'll add this to
the TODO list. ;)
Thanks for double-checking.
--
Kees Cook
Powered by blists - more mailing lists