From owner-svn-src-all@freebsd.org Wed Apr 17 18:08:22 2019 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 46C941574A52; Wed, 17 Apr 2019 18:08:22 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C18FE8BEA2; Wed, 17 Apr 2019 18:08:21 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io1-f48.google.com with SMTP id p16so21406174iod.2; Wed, 17 Apr 2019 11:08:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=25UmBtc9HFlYLIS8E/28Z8IXOIrF2VTG7EPUUutq/6Q=; b=JY3DMcAQxGYrBxVd6RhZNYEFu01ETwIpp8DFkg2/djEzvUkBS04TF5iyy5ov9qek2w OYLMt4lgmDmAk4wKDduse5g2W5f87As77LSrNCXDqIeloVcFZdsLgdhycoRkshZLdENe 4WTsvo6twYvQgrhXEQgqZ5G4QVxE3nqcuMmXXJYq85WMNtCV93bMnmUyp9tIaNHnb9f0 tXrJ88RY6mGUYuKTMMXj+LM4Tv7WAfTCF2nX9gtBhDVElPwUGroqAJTl48AhtXkZeNOo US4FsVG+DllVwVunjXAMoTehfDUOoWhg4SDGliJl7Ke22fc/Bc26sKCRMLBwgeiJirMP IvSA== X-Gm-Message-State: APjAAAX1rnTHlit4e9qwWXnu3OBtnBXW5zksdyeJPPueQyQNpRXDaEld 097fboacd/KRxHT3s60+5pioPjmm X-Google-Smtp-Source: APXvYqzUuEtB2fD8OpXjCrZsyO15AMev9y3xEwFJ/F3NUZaLEVICbtEdNNmiwBDGOq6DQI1qXDOHHg== X-Received: by 2002:a5e:d510:: with SMTP id e16mr773614iom.297.1555524021294; Wed, 17 Apr 2019 11:00:21 -0700 (PDT) Received: from mail-it1-f179.google.com (mail-it1-f179.google.com. [209.85.166.179]) by smtp.gmail.com with ESMTPSA id v23sm20398139ioq.6.2019.04.17.11.00.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Apr 2019 11:00:21 -0700 (PDT) Received: by mail-it1-f179.google.com with SMTP id 139so5846283ita.4; Wed, 17 Apr 2019 11:00:21 -0700 (PDT) X-Received: by 2002:a05:6638:28c:: with SMTP id c12mr33927696jaq.87.1555524020968; Wed, 17 Apr 2019 11:00:20 -0700 (PDT) MIME-Version: 1.0 References: <201904151840.x3FIeaEQ009242@repo.freebsd.org> <457a2c63-f062-8fc6-15d4-6f5b93981930@FreeBSD.org> <5d790a56-1498-094e-6bb4-48345a231e55@FreeBSD.org> <383a21de-9a7a-2d06-1673-001e84af67f9@FreeBSD.org> In-Reply-To: <383a21de-9a7a-2d06-1673-001e84af67f9@FreeBSD.org> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Wed, 17 Apr 2019 11:00:10 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: svn commit: r346250 - in head: share/man/man4 share/man/man9 sys/dev/random sys/kern sys/libkern sys/sys To: John Baldwin Cc: src-committers , svn-src-all , svn-src-head Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: C18FE8BEA2 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; REPLY(-4.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.987,0]; TAGGED_FROM(0.00)[] X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 18:08:22 -0000 Hi John, On Wed, Apr 17, 2019 at 9:01 AM John Baldwin 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