From owner-svn-src-all@freebsd.org Tue Apr 16 23:43:48 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 0A0A61580F62; Tue, 16 Apr 2019 23:43:48 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io1-f44.google.com (mail-io1-f44.google.com [209.85.166.44]) (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 937AB85D0E; Tue, 16 Apr 2019 23:43:47 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io1-f44.google.com with SMTP id v10so19117088iom.8; Tue, 16 Apr 2019 16:43:47 -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=Qy24jlWnhqpQBTPNsTSLPfsDiCMvmd25HGwOVMlFXow=; b=QSTnTOzWQ96bpYpcvz+hidxk7fqq/lwPghJwPt0DP5vwpQ/yeqb3FzFs0QR/F6IAUJ LNupIozUP5aPFIBE+gUarCI/tMm0JkjvWuiSYHDG6ZZnsCilK9pV9OC1wiryKdsh5y6m 5a3fTVNeExJJmMn31g9wEdi/UajxHcQXMogneVWsjhJJN34XR8hJslTxvX8eT2XtQlyc nc0R0af86sCGHx8rzMUqNYELWIZcJGvu5JTs84abSKv44BGY2oXuVUdY43C/BULS5tcZ yKm2e4OUDx+qULQdAczPs20eW5jrliRDGXwEfky/cNHsSKPUoOOcUlrquQinryz6pVH1 gVmA== X-Gm-Message-State: APjAAAUoZQdHAVxZ7AhTkUsCdMarj2XiZfl/ZkvQsh4b5OPT8sVTtEbp 9eFGhljnkjIVV0mbaVrQhsAcgivF X-Google-Smtp-Source: APXvYqwcrj7OtcJRy++5fhmehGD5wFv/J50bH8JjnN/7oAsAwMjVxsLO+PdsyqlvAaIltWC2NnZ3Zw== X-Received: by 2002:a6b:e317:: with SMTP id u23mr3060182ioc.206.1555458220645; Tue, 16 Apr 2019 16:43:40 -0700 (PDT) Received: from mail-io1-f51.google.com (mail-io1-f51.google.com. [209.85.166.51]) by smtp.gmail.com with ESMTPSA id f14sm20181470ion.46.2019.04.16.16.43.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 16 Apr 2019 16:43:40 -0700 (PDT) Received: by mail-io1-f51.google.com with SMTP id u12so19075363iop.11; Tue, 16 Apr 2019 16:43:40 -0700 (PDT) X-Received: by 2002:a6b:8b90:: with SMTP id n138mr10196268iod.75.1555458220164; Tue, 16 Apr 2019 16:43:40 -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> In-Reply-To: <5d790a56-1498-094e-6bb4-48345a231e55@FreeBSD.org> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Tue, 16 Apr 2019 16:43:22 -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: 937AB85D0E X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 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.97)[-0.973,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: Tue, 16 Apr 2019 23:43:48 -0000 On Tue, Apr 16, 2019 at 4:28 PM John Baldwin wrote: > Yes, but we need some kind of non-blocking API, not an unconditionally-blocking API > that deadlocks. I'm not sure we do. It would be sufficient to check once at subsystem initialization time. There's no race condition such that we block again once we're seeded. As far as APIs go, read_random_uio is nonblocking, although not an arc4random interface (and quite cumbersome to set up and use). > Eh, I thought that we periodically pulled in new entropy to generate a new chacha20 > key for the PRNG and that could be blocking as well when I was last reading this > code, or is that not correct? No, that's incorrect. We periodically pull new Fortuna (devrandom) output to reseed chacha20 in arc4random, but once Fortuna is "seeded," it *never* blocks ever again. > Or maybe arc4random passes in a flag to disable > reseeding so it isn't blocking once the PRNG has been seeded at least once? As above, *re*seeding arc4random never blocks. > Still, what I would suggest is to have the existing arc4random() use WITNESS_WARN. > We could provide an alternative API that is non-blocking and returns EWOULDBLOCK. I think the alternative EWOULDBLOCK proposal is worse than WITNESS_WARN. But I highlighted some problems with WITNESS_WARN in my earlier email; how would you resolve them? > Code that trips over the warning would have to be changed to use the non-blocking > API and then deal with EWOULDBLOCK. Or it could just check that the random device is seeded, prior to using arc4random? > One way of dealing with that would be to > check the is_random_seeded() flag earlier in the function, subsystem, whatever > and then the code could assert that the non-blocking API never failed. That's more or less the status quo with no-error arc4random, no? > There are things like virtio-rng for modern x86 VM environments, but those don't > exist on things like the MIPS MALTA machine. They probably probe later than SI_SUB_RANDOM too :-(. > I also don't actually care at all (as in > absolutely zero) about the entropy of keys generated for a test qemu instance I fire up > on my desktop that doesn't permit inbound access from the outside world. Having some > kind of tunable / kernel option for those use cases (that isn't the default) doesn't > seem unreasonable. Sure. It would probably be ok to have a knob for that. We would want to be careful about naming it / documenting it; the thing about knobs is people tend to twiddle them. Best, Conrad