Date: Wed, 17 Apr 2019 11:00:10 -0700 From: Conrad Meyer <cem@freebsd.org> To: John Baldwin <jhb@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: <CAG6CVpXR_0qu=V8gucQoJTvi-zEDiQ-b11U%2Bm6EduL%2Bq13D_%2Bg@mail.gmail.com> In-Reply-To: <383a21de-9a7a-2d06-1673-001e84af67f9@FreeBSD.org> 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> <383a21de-9a7a-2d06-1673-001e84af67f9@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi John, On Wed, Apr 17, 2019 at 9:01 AM John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpXR_0qu=V8gucQoJTvi-zEDiQ-b11U%2Bm6EduL%2Bq13D_%2Bg>