Initial support for bcm2838 RNG

[Conrad Meyer]

I don’t think csprng’s blocker level review requirement extends to
individual drivers, but I might be mistaken. The kind of things we care
about (imo) are, in order: the core randomdev device, the Fortuna
implementation, the generic entropy gathering, and that entropy  data can
only be used once — don’t expose it to a user and also feed it to
randomdev. Also, arc4random et al.

Personally, I don’t have the expertise with this particular hardware to
find anything objectionable about this change. The actual change to the
harvest function in this driver is de minimis. As far as I’m concerned, it
looks good to me; ship it!



On Sun, Nov 17, 2019 at 06:29 Kyle Evans <kevans at freebsd.org> wrote:

> On Sun, Nov 17, 2019 at 4:03 AM Mark Murray <markm at freebsd.org> wrote:
> >
> > Hi,
> >
> > > On 16 Nov 2019, at 18:59, Kyle Evans <kevans at FreeBSD.org> wrote:
> > >
> > > On Sat, Nov 16, 2019 at 12:48 PM Robert Crowston via freebsd-arm
> > > <freebsd-arm at freebsd.org> wrote:
> > >>
> > >> I have made a first cut at supporting the Broadcom 2838 hardware
> random number generator, as found on the Raspberry Pi 4.
> > >>
> > >> Diff:
> https://github.com/freebsd/freebsd/compare/master...RobCrowston:pi4-hwrng
> > >>
> > >> This extends the existing bcm2835_rng.c driver to function on the
> Pi4. Unfortunately I do not have a Raspberry Pi 3 board to confirm it still
> works there, but on my Pi4, it generates (apparently) random numbers.
> > >>
> > >
> > > Hi,
> > >
> > > No worries- I've got access to a Pi 3 for regression testing. Can you
> > > throw what you've got into Phabricator [0] and add me as a reviewer?
> > > We can iterate/review from there.
> >
> > Please also add markm@ and cem@ (or csprng@). You'll need one of us to
> OK the commit.
> >
>
> Hi, (adding cem@ to CC list)
>
> Is there a document or something outlining what csprng@ wants to
> accomplish? I definitely don't object to adding you guys on this one
> (both because of the csprng@ origin story and this touches just enough
> actual RNG code path to warrant it, at a glance), but going forward-
> is csprng@ wanting to audit pre-existing stuff as it gets touched in
> any way (e.g. existing driver, just adding compatibility bits to make
> it probe/attach on new board), or just any new code actually affecting
> RNG?
>
> Thanks,
>
> Kyle Evans
>