svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys

[John Baldwin]

On 4/16/19 4:43 PM, Conrad Meyer wrote:
> On Tue, Apr 16, 2019 at 4:28 PM John Baldwin <jhb at 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