From owner-svn-src-all@freebsd.org Tue Sep 3 14:07:52 2019 Return-Path: Delivered-To: svn-src-all@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 936C0DD29B; Tue, 3 Sep 2019 14:06:59 +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 46N803033mz4Q6W; Tue, 3 Sep 2019 14:06:59 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 0FAFF1AE8D; Tue, 3 Sep 2019 14:06:24 +0000 (UTC) X-Original-To: yuripv@localmail.freebsd.org Delivered-To: yuripv@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (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 3C8AA623E; Tue, 16 Apr 2019 22:56:05 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 4C76E840DC; Tue, 16 Apr 2019 22:56:04 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 2C76E620B; Tue, 16 Apr 2019 22:56:04 +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 E907B6208; Tue, 16 Apr 2019 22:56:00 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) (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 90498840D7; Tue, 16 Apr 2019 22:56:00 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io1-f67.google.com with SMTP id f6so19063381iop.3; Tue, 16 Apr 2019 15:56:00 -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=41VlXKvpyvUQSkyagsxvTJMsN5lzY6HrHdtrkLoGMx8=; b=RYy/XjI1wV3RLHXZ7JHngF8XeSXySOoghwcyt949OCSy0c1G8jmmZMm0wM5Zp0zZJV SuRpYxdBCxASA57UItW0Nk5J8QK9N00Tjt9Q1nayGLPu2kyh3zlC0acaqNgs7T6oLQMB 9RlJ0NyF2DyyM5y7NTtLT9nLUQkVOZrBBkEpn8h46YcFdiXVbfVe0T+6cnbyYpp8XOSn 6ULp0f3sRviYuXElsZ5lZtmRt01/QWEMnfSwlXCHBGVj/LA0QbxsfE0cN4AY+VKagdzQ BrHmsfxSOKH/+PRSdz7gGUVBd8G279Oj/L0et6+J7sle/nhhjsB7D5JNhPEA4XfxqDp3 6iLA== X-Gm-Message-State: APjAAAXmsJrJ6VBfkdhffIy83KkIHgNpyKlOIP12OQcaYdon8QLKmjSK 1VHqQG5K6JOaq6lc+M0D5Q3Qj0Nv X-Google-Smtp-Source: APXvYqytdlVO3ff9kEMmgd48JJi0LCrW0ZECcg8O5KkPe6FznxkHNxIl8IupFySE+4GYDJZ61nw9uA== X-Received: by 2002:a6b:f317:: with SMTP id m23mr39953939ioh.136.1555454966712; Tue, 16 Apr 2019 15:49:26 -0700 (PDT) Received: from mail-io1-f47.google.com (mail-io1-f47.google.com. [209.85.166.47]) by smtp.gmail.com with ESMTPSA id o203sm390551itd.1.2019.04.16.15.49.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Apr 2019 15:49:26 -0700 (PDT) Received: by mail-io1-f47.google.com with SMTP id s7so19009243iom.12; Tue, 16 Apr 2019 15:49:26 -0700 (PDT) X-Received: by 2002:a6b:8b90:: with SMTP id n138mr10045058iod.75.1555454966164; Tue, 16 Apr 2019 15:49:26 -0700 (PDT) MIME-Version: 1.0 References: <201904151840.x3FIeaEQ009242@repo.freebsd.org> <457a2c63-f062-8fc6-15d4-6f5b93981930@FreeBSD.org> In-Reply-To: <457a2c63-f062-8fc6-15d4-6f5b93981930@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: 4C76E840DC X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Status: O X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 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: , Date: Tue, 03 Sep 2019 14:07:52 -0000 X-Original-Date: Tue, 16 Apr 2019 15:49:14 -0700 X-List-Received-Date: Tue, 03 Sep 2019 14:07:52 -0000 On Tue, Apr 16, 2019 at 2:32 PM John Baldwin wrote: > There are definitely places arc4random is used where sleeping is not allowed. Sure. > ipsec generating nonces for AES-CBC is one example I can think of off the > top of my head. IVs for AES-CBC are also a great example of a case we should be seeded for. > I think it might be useful to add an explicit WITNESS_WARN > in arc4random to catch these cases so they can be found and reasoned about. Well, we kind of want that, but we also want the warning to disappear if the consumer has correctly reasoned about it. E.g., if the thread has verified seeded status with is_random_seeded(), it is no longer possible for a arc4random consumption to block. Right? I think that may be difficult to integrate with the WITNESS_WARN, so even if all consumers are correctly implemented, we will not eliminate the witness warnings. Do you have any ideas? The only dumb proposal I have is burning a flag in td_flags for "this thread checked is_random_seeded(), and it returned true." > Note that I actually often run into unseeded systems when doing development > using qemu for non-x86 architectures. For example, when booting mips from > qemu, there is no loader, the kernel just starts, and since the endian is > opposite, I frequently regenerate the filesystem using makefs. Right. Perhaps we could incorporate boot/entropy generation into makefs? Or pass host entropy into some kernel accessible region (env var, whatever) via qemu? The latter is sort of a general problem for VMs. You want to be able to snapshot and clone a VM without producing reproducible RNG state, but Fortuna doesn't handle that explicitly (aside from future entropy differences and forward secrecy causing quick divergence). Best, Conrad