Date: Sun, 17 Nov 2019 10:02:11 -0800 From: Conrad Meyer <cem@freebsd.org> To: Kyle Evans <kevans@freebsd.org> Cc: Conrad Meyer <cem@freebsd.org>, Mark Murray <markm@freebsd.org>, Robert Crowston <crowston@protonmail.com>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Initial support for bcm2838 RNG Message-ID: <CAG6CVpXOXTUrrVaNOi_6QxsdkgvrodeaOkft7Q%2B18sLDhPmS%2Bw@mail.gmail.com> In-Reply-To: <CACNAnaFxiEP8sZ0HLw1%2BpiRMYqivCyby349FMJjtHTXz3-ve4A@mail.gmail.com> References: <w0qoeMk_XAZYjTShtjgVdPgjrbL3HOfYBcoT-XZeGohC-W3S0THV3dFJXrm51PhYxgkth3M75DszWna9o-OXXS6rPjOeCAUJyNVmlbV0kUU=@protonmail.com> <CACNAnaGUwZ9d0_MFOh7SsG7mDqbZTAym=dqXQRW_Y3CH%2Bai%2BdA@mail.gmail.com> <2F178D6A-300B-4683-84D6-CDB6924877E5@FreeBSD.org> <CACNAnaFxiEP8sZ0HLw1%2BpiRMYqivCyby349FMJjtHTXz3-ve4A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I don=E2=80=99t think csprng=E2=80=99s blocker level review requirement ext= ends 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 =E2=80=94 don=E2=80=99t expose it to a user and also feed= it to randomdev. Also, arc4random et al. Personally, I don=E2=80=99t have the expertise with this particular hardwar= e to find anything objectionable about this change. The actual change to the harvest function in this driver is de minimis. As far as I=E2=80=99m concer= ned, it looks good to me; ship it! On Sun, Nov 17, 2019 at 06:29 Kyle Evans <kevans@freebsd.org> wrote: > On Sun, Nov 17, 2019 at 4:03 AM Mark Murray <markm@freebsd.org> wrote: > > > > Hi, > > > > > On 16 Nov 2019, at 18:59, Kyle Evans <kevans@FreeBSD.org> wrote: > > > > > > On Sat, Nov 16, 2019 at 12:48 PM Robert Crowston via freebsd-arm > > > <freebsd-arm@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 sti= ll > 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpXOXTUrrVaNOi_6QxsdkgvrodeaOkft7Q%2B18sLDhPmS%2Bw>