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

[Conrad Meyer]

Hi John,

On Wed, Apr 17, 2019 at 9:01 AM John Baldwin <jhb at freebsd.org> wrote:
> You're missing the point which is that you've added potential blocking in a lot of
> places by changing the semantics of arc4random.

I get it.  The thing is, it's a weird blocking semantic.  It's not the
same as any other blocking semantic we have elsewhere in the kernel.
It can't happen in any particular call.  Once it unblocks, it's
nonblocking forever after.  So if the caller a priori knows that
random is seeded, it's not a blocking operation.

> 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.

This would essentially just force auditing, no?  I guess it helps
highlight instances that are (a) actually inside a locked region and
(b) run by users.  I'm on board with this approach.  My only concern
is that we will have false positives (and continue to have false
positives after true positives are made safe).  One thing we could do
is teach WITNESS about random's seeded/not status.

Let's take away: I'll owe you a differential implementing some version
of this proposal, as well as a separate one for the giant
unsafe-random knob, and we can discuss the technical details offline.
Expect something today, if at all possible.

> 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.

Ok; if it is attached to a specific need, and it has
'__attribute__((warn_unused_result))' attached to it, I'm tentatively
ok with the idea.  I don't want to add additional interfaces that
don't get used, or make it easy to accidentally get non-results.

Best regards,
Conrad