From nobody Sun Feb 13 01:27:15 2022 X-Original-To: dev-commits-src-branches@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 53CDD1954239; Sun, 13 Feb 2022 01:27:28 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Jx8q35VGFz4mXb; Sun, 13 Feb 2022 01:27:27 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644715648; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rLiNyKF323ynyRHgxaU5JfeY/Wu5L3go9Ykdtz821Bo=; b=Kq/T487Wlw32ZzMK4uW997x5XpGYz59CHWVskO9ziR1ytnt3hDU70978WiOZrv5KXBbI3G IuyKKggdr0W5j+nRCpryunjZ10siLpXKvV7gYUxYo4+x68wwNRUtDW1+L7ZGAW24Dju6S5 JsfbF5eVpSnkNKJcaHol/4qGYbVBOaRxIuc0uRLkhGLxP+4unQpJVTfP4xrcy9pJKryCk0 7NKeMY6kplSKydN0dICD8He/UZvfo5BuoIrXGJTqZj5XFSWTiusIA4u2UMPzXMKM+hxtXJ kETKi50ocGhmKFuqtS2zLaasY9UHYIUVrqKqJlB4Ops+nhwwen7wrQY4wipE2w== Received: from mail-qk1-f177.google.com (mail-qk1-f177.google.com [209.85.222.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 0A3C12DAFB; Sun, 13 Feb 2022 01:27:26 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f177.google.com with SMTP id o12so11512008qke.5; Sat, 12 Feb 2022 17:27:26 -0800 (PST) X-Gm-Message-State: AOAM532UcdNZMJIsFLP7hwR7Gt+6o0PSyP+KdqmlbZhfdH423a3cwsBb fC4Uxo0pue+i8rTxjJaj43jShsa7N+kbs9tZwfk= X-Google-Smtp-Source: ABdhPJyHTlqkWgxTUjlQlEX98fakR2zTBPvqBOPw5c4XMCgFinaBNg3BKj+YbT/JWBAVS0FwHlrs6Xxus9v0LWht13U= X-Received: by 2002:a37:b584:: with SMTP id e126mr1307763qkf.365.1644715646158; Sat, 12 Feb 2022 17:27:26 -0800 (PST) List-Id: Commits to the stable branches of the FreeBSD src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-branches List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-branches@freebsd.org X-BeenThere: dev-commits-src-branches@freebsd.org MIME-Version: 1.0 References: <202202130122.21D1Mkms038731@gitrepo.freebsd.org> In-Reply-To: <202202130122.21D1Mkms038731@gitrepo.freebsd.org> From: Kyle Evans Date: Sat, 12 Feb 2022 19:27:15 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: git: e9c023a47aed - stable/12 - random(4): Block read_random(9) on initial seeding To: "David E. O'Brien" Cc: src-committers , "" , dev-commits-src-branches@freebsd.org Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644715648; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rLiNyKF323ynyRHgxaU5JfeY/Wu5L3go9Ykdtz821Bo=; b=v8Nl7bF8UlFSfOpDd3gtm35mr9uFiSK3JLwv6skXFyO2ULi1cS6PjtvSZnrNBrWaIcoyZ+ CYUe9WxPM0islzYdAeKqfJqoyJlCzwdqqyRTTWu0BV5LqK5iteDM3Jm1URWFouN5+zSGp6 TQ13isJqvOCT716JRcOBJBXG62OYOur6s0GjnInEnJSUoj+nzeITuq2k7rUlHgUvI5pt2y n+1lnU5epi1Mo0Jhb3KiItf0/YltF1hkkGcxBNt2Otitxvte3a4wCIeSol6wnKqV9tx9QM XxDfP7NJNAevzQVhscmJILqsfasvleix37eMmBtXXUsz2x4B1oZjA985QtSsLQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644715648; a=rsa-sha256; cv=none; b=u3e5JpHqkKBYy5ZZPiHVrV/ikJvTZ/UD6LyrXigIB2UB65mndV1iCO8mfzS8Nq+sSY0xLy EmGRPPKvR9mluv0lBRkp8QTDtVrOKtAzhBJuRxqeM1aHbhJSU6X6uRW//fP4qI4ZYS8x+s Fy5VszaIVv3DBXaIgMc1/5wkXb+dvXYEx0mm2pZR9QDLi70k0wArJqpSKG/rKoTrQS1kiY w7zXP370B+ovBtyIHRKf+o9byF6B8jd6sINaqKqDV9WlmmYcIwG6gKz4E92lImkLDaZVvM GTHviWw2/Q6Qgo7Z2IoJ1hB3mg+yZ0uLz0wafr5DB4/JPwMDdiPJgn5n3WGBwQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Sat, Feb 12, 2022 at 7:22 PM David E. O'Brien wrote: > > The branch stable/12 has been updated by obrien: > > URL: https://cgit.FreeBSD.org/src/commit/?id=e9c023a47aedb678c7fdb470f05cfed8dba2586e > > commit e9c023a47aedb678c7fdb470f05cfed8dba2586e > Author: Conrad Meyer > AuthorDate: 2019-04-15 18:40:36 +0000 > Commit: David E. O'Brien > CommitDate: 2022-02-13 00:32:39 +0000 > > random(4): Block read_random(9) on initial seeding > > read_random() is/was used, mostly without error checking, in a lot of > very sensitive places in the kernel -- including seeding the widely used > arc4random(9). > > Most uses, especially arc4random(9), should block until the device is seeded > rather than proceeding with a bogus or empty seed. I did not spy any > obvious kernel consumers where blocking would be inappropriate (in the > sense that lack of entropy would be ok -- I did not investigate locking > angle thoroughly). In many instances, arc4random_buf(9) or that family > of APIs would be more appropriate anyway; that work was done in r345865. > > A minor cleanup was made to the implementation of the READ_RANDOM function: > instead of using a variable-length array on the stack to temporarily store > all full random blocks sufficient to satisfy the requested 'len', only store > a single block on the stack. This has some benefit in terms of reducing > stack usage, reducing memcpy overhead and reducing devrandom output leakage > via the stack. Additionally, the stack block is now safely zeroed if it was > used. > > One caveat of this change is that the kern.arandom sysctl no longer returns > zero bytes immediately if the random device is not seeded. This means that > FreeBSD-specific userspace applications which attempted to handle an > unseeded random device may be broken by this change. If such behavior is > needed, it can be replaced by the more portable getrandom(2) GRND_NONBLOCK > option. > > On any typical FreeBSD system, entropy is persisted on read/write media and > used to seed the random device very early in boot, and blocking is never a > problem. > > This change primarily impacts the behavior of /dev/random on embedded > systems with read-only media that do not configure "nodevice random". We > toggle the default from 'charge on blindly with no entropy' to 'block > indefinitely.' This default is safer, but may cause frustration. Embedded > system designers using FreeBSD have several options. The most obvious is to > plan to have a small writable NVRAM or NAND to persist entropy, like larger > systems. Early entropy can be fed from any loader, or by writing directly > to /dev/random during boot. Some embedded SoCs now provide a fast hardware > entropy source; this would also work for quickly seeding Fortuna. A 3rd > option would be creating an embedded-specific, more simplistic random > module, like that designed by DJB in [1] (this design still requires a small > rewritable media for forward secrecy). Finally, the least preferred option > might be "nodevice random", although I plan to remove this in a subsequent > revision. > > To help developers emulate the behavior of these embedded systems on > ordinary workstations, the tunable kern.random.block_seeded_status was > added. When set to 1, it blocks the random device. > > I attempted to document this change in random.4 and random.9 and ran into a > bunch of out-of-date or irrelevant or inaccurate content and ended up > rototilling those documents more than I intended to. Sorry. I think > they're in a better state now. > > PR: 230875 > Reviewed by: delphij, markm (earlier version) > Approved by: secteam(delphij), devrandom(markm) > Relnotes: yes > Differential Revision: https://reviews.freebsd.org/D19744 > > (cherry picked from commit 13774e82285e8d5eb3afeff63760725f747f8581) fwiw, I think this should have been squashed with an MFC of 3782136ff1fc1e076c939246f199e659d950bad5, which was a follow-up fix/concession. Thanks, Kyle Evans