Date: Tue, 03 Sep 2019 14:07:15 -0000 From: John Baldwin <jhb@FreeBSD.org> To: cem@freebsd.org Cc: src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys Message-ID: <383a21de-9a7a-2d06-1673-001e84af67f9@FreeBSD.org> In-Reply-To: <CAG6CVpXS2Mv61c8pHWUVOQJJZotHkniuGuTBQRnbftJ7ULZLag@mail.gmail.com> References: <201904151840.x3FIeaEQ009242@repo.freebsd.org> <457a2c63-f062-8fc6-15d4-6f5b93981930@FreeBSD.org> <CAG6CVpWu3eaCqe2cYS8FdAna30q58UT3KTiYHjxfv7Yo052dDg@mail.gmail.com> <5d790a56-1498-094e-6bb4-48345a231e55@FreeBSD.org> <CAG6CVpXS2Mv61c8pHWUVOQJJZotHkniuGuTBQRnbftJ7ULZLag@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/16/19 4:43 PM, Conrad Meyer wrote: > On Tue, Apr 16, 2019 at 4:28 PM John Baldwin <jhb@freebsd.org> wrote: >> Still, what I would suggest is to have the existing arc4random() use WITNESS_WARN. >> We could provide an alternative API that is non-blocking and returns EWOULDBLOCK. > > I think the alternative EWOULDBLOCK proposal is worse than > WITNESS_WARN. But I highlighted some problems with WITNESS_WARN in my > earlier email; how would you resolve them? > >> Code that trips over the warning would have to be changed to use the non-blocking >> API and then deal with EWOULDBLOCK. > > Or it could just check that the random device is seeded, prior to > using arc4random? You're missing the point which is that you've added potential blocking in a lot of places by changing the semantics of arc4random. Unless you're intending to hand-audit all of them (as well as future uses), I think having the existing API be "safe" (and blocking) but use WITNESS_WARN is a way to catch existing and future locking problems. The EWOULDBLOCK API is something a developer would choose and it means they would be aware of the constraint and need to deal with it, either by handling EWOULDBLOCK in some way, or deferring use until seeded, etc. >> One way of dealing with that would be to >> check the is_random_seeded() flag earlier in the function, subsystem, whatever >> and then the code could assert that the non-blocking API never failed. > > That's more or less the status quo with no-error arc4random, no? Except that we don't know which existing or future uses of arc4random need this unless you manually audit all of them (which doesn't help future uses). -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?383a21de-9a7a-2d06-1673-001e84af67f9>