From owner-svn-src-head@freebsd.org Tue Sep 3 14:07:18 2019 Return-Path: Delivered-To: svn-src-head@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 549AFDD35F; Tue, 3 Sep 2019 14:07:02 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46N8054Q3bz4Q9X; Tue, 3 Sep 2019 14:07:01 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 4CF8F1AF93; Tue, 3 Sep 2019 14:06:26 +0000 (UTC) X-Original-To: yuripv@localmail.freebsd.org Delivered-To: yuripv@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id E36B4152C8; Wed, 17 Apr 2019 18:08:25 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 470E78BEA9; Wed, 17 Apr 2019 18:08:25 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 1B1EE15283; Wed, 17 Apr 2019 18:08:25 +0000 (UTC) Delivered-To: src-committers@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 1920515280; 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 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" Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 470E78BEA9 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_SHORT(-0.99)[-0.990,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 03 Sep 2019 14:07:18 -0000 X-Original-Date: Wed, 17 Apr 2019 11:00:10 -0700 X-List-Received-Date: Tue, 03 Sep 2019 14:07:18 -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