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>
index | next in thread | previous in thread | raw e-mail
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@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 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 >help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpXOXTUrrVaNOi_6QxsdkgvrodeaOkft7Q%2B18sLDhPmS%2Bw>