Date: Tue, 03 Sep 2019 14:07:58 -0000 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Warner Losh <imp@bsdimp.com> Cc: "Rodney W. Grimes" <rgrimes@freebsd.org>, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, Kyle Evans <kevans@freebsd.org>, Cy Schubert <cy@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r346341 - head/tools/build Message-ID: <3E54A972-27CE-498F-B0B9-B65A6E87F213@cschubert.com> In-Reply-To: <CANCZdfqz4uueMc3qyXeyoODS%2BEyrf4GvNJVc7A4mftim%2BKdPig@mail.gmail.com> References: <201904181422.x3IEMrux005930@gndrsh.dnsmgr.net> <3095E422-7865-4EA5-BF13-6A48CB542AEE@cschubert.com> <CANCZdfrkON8J_6ZHt1UKa95G0=JLwZ8KoebspZzF0%2BeQ71BY4A@mail.gmail.com> <AA719490-5A6F-4218-90B8-FB7FA724C94E@cschubert.com> <CANCZdfqz4uueMc3qyXeyoODS%2BEyrf4GvNJVc7A4mftim%2BKdPig@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On April 18, 2019 9:59:50 AM PDT, Warner Losh <imp@bsdimp=2Ecom> wrote: >On Thu, Apr 18, 2019 at 10:26 AM Cy Schubert ><Cy=2ESchubert@cschubert=2Ecom> >wrote: > >> On April 18, 2019 8:11:49 AM PDT, Warner Losh <imp@bsdimp=2Ecom> wrote: >>> >>> >>> >>> On Thu, Apr 18, 2019 at 8:44 AM Cy Schubert ><Cy=2ESchubert@cschubert=2Ecom> >>> wrote: >>> >>>> On April 18, 2019 7:22:53 AM PDT, "Rodney W=2E Grimes" < >>>> freebsd@gndrsh=2Ednsmgr=2Enet> wrote: >>>> >> On Thu, Apr 18, 2019 at 8:46 AM Rodney W=2E Grimes >>>> >> <freebsd@gndrsh=2Ednsmgr=2Enet> wrote: >>>> >> > >>>> >> > > In message <201904180107=2Ex3I17QDc002945@gndrsh=2Ednsmgr=2Ene= t>, >>>> >"Rodney W=2E >>>> >> > > Grimes" >>>> >> > > writes: >>>> >> > > > > Author: cy >>>> >> > > > > Date: Thu Apr 18 01:02:00 2019 >>>> >> > > > > New Revision: 346341 >>>> >> > > > > URL: https://svnweb=2Efreebsd=2Eorg/changeset/base/346341 >>>> >> > > > > >>>> >> > > > > Log: >>>> >> > > > > As an interim measure until a more permanent solution >is >>>> >implemented >>>> >> > > > > workaround the following error: >>>> >> > > > > >>>> >> > > > > =20 >/usr/src/contrib/elftoolchain/strings/strings=2Ec:198:55: >>>> >error: use of >>>> >> > > > > undeclared identifier >>>> >> > > > > 'FA_OPEN' fa =3D fileargs_init(argc, argv, O_RDONLY, 0, >>>> >&rights, FA_OPEN); >>>> >> > > > > >>>> >> > > > > Reported by: O=2E Hartmann <ohartmann@walstatt=2Eorg> >>>> >> > > > > Reported by: Michael Butler ><imb@protected-networks=2Enet> >>>> >> > > > > Reported by: gjb@ & cy@ (implicit) >>>> >> > > > > Reviewed by: emaste@ >>>> >> > > > > Noted by: rgrimes@ >>>> >> > > > > >>>> >> > > > > Modified: >>>> >> > > > > head/tools/build/Makefile >>>> >> > > > > >>>> >> > > > > Modified: head/tools/build/Makefile >>>> >> > > > > >>>> >>>> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>>> >> > > > =3D=3D=3D >>>> >> > > > > --- head/tools/build/Makefile Thu Apr 18 00:38:54 >2019 >>>> > (r34634 >>>> >> > > > 0) >>>> >> > > > > +++ head/tools/build/Makefile Thu Apr 18 01:02:00 >2019 >>>> > (r34634 >>>> >> > > > 1) >>>> >> > > > > @@ -59,9 +59,7 @@ INCS+=3D capsicum_helpers=2Eh >>>> >> > > > > INCS+=3D libcasper=2Eh >>>> >> > > > > =2Eendif >>>> >> > > > > >>>> >> > > > > -=2Eif !exists(/usr/include/casper/cap_fileargs=2Eh) >>>> >> > > > > CASPERINC+=3D >>>> >${SRCTOP}/lib/libcasper/services/cap_fileargs/cap_filea >>>> >> > > > rgs=2Eh >>>> >> > > > > -=2Eendif >>>> >> > > > >>>> >> > > > As a further note, we should probably hunt for any thing >>>> >> > > > that is explicity looking at /usr/include/=2E=2E=2E in a >Makefile, >>>> >> > > > as that is minimally missing a ${DESTDIR} argument=2E >>>> >> > > > >>>> >> > > > The above may of actually worked if it had been written: >>>> >> > > > =2Eif !exists(${DESTDIR}/usr/include/casper/cap_fileargs=2Eh= ) >>>> >> > > > someone may wish to test that=2E >>>> >> > > > >>>> >> > > > Also a pathname rooted at / without ${DESTDIR} is almost >>>> >certainly a mistake=2E >>>> >> > > >>>> >> > > This is a better solution=2E I tested this in a tree with a >>>> >duplicated >>>> >> > > environment: Problem solved=2E Before this is committed it >should >>>> >be >>>> >> > > tested on one of the universe machines=2E >>>> >> > >>>> >> > From what Ed just said this would also be wrong, >>>> >> > as well as CASPERINC+=3D above being wrong, if this >>>> >> > is being built for the host we should not be using >>>> >> > any headers from ${SRCTOP} at all=2E >>>> >> > >>>> >> > if capfileargs=2Eh does not exist on the host that functionality >>>> >> > must not be compiled into the buildtool as the host does not >>>> >> > have this feature and attempting to use it from SRCTOP is >wrong=2E >>>> >> > >>>> >> >>>> >> Keep in mind that this is bootstrap; it's being built for the >host >>>> >> system, but it will link against a version of libcasper that's >been >>>> >> built in an earlier stage with the proper featureset=2E >>>> > >>>> >Ok, flip flop again, if infact this is linked against a >>>> >library that implements the stuff from cap_fileargs=2Eh then >>>> >infact the ${DESTDIR} addition so that the build peaks into >>>> >the cross build tree is correct, or what ever the equivelent >>>> >to DESTDIR is for that ? BUILDDIR? The point is it should >>>> >be picking this header up from the object tree, NOT from >>>> >the running system=2E >>>> >>>> Yes, this was my conclusion when working on kerberos and ntp=2E This >is >>>> also true of libraries, else one would need to installworld and >buildworld >>>> again to get a properly built library/binary=2E >>>> >>>> IIRC ngie@ fixed a number of these across the tree a couple of >years >>>> ago=2E >>> >>> >>> OK=2E There's a number of different issues going on=2E As the original >author >>> of libegacy (which is what we're seeing fail), let me address the >design >>> generically and comment on different things that have come up in >this >>> thread=2E >>> >>> Since this is going into the libegacy that we're using to build the >>> system, the check for file is bogus, for reasons I'll discuss below=2E > When >>> we add new includes to the system, it is appropriate to do it this >way=2E And >>> when this file was added to the system, the check was correct=2E >>> >>> First off, DESTDIR is absolutely not correct since this is to build >the >>> legacy library and legacy includes which augment the host's sources >on >>> legacay system, hence the name=2E It's never the correct thing to use= =2E >>> >>> The problem that we have here is not that the file is missing (which >is >>> why it was added the way it was a long time ago), but rather missing >>> functionality in a file that's been around for a long time=2E >>> >>> So, since it is that class of problem, the canonical way we've dealt >with >>> it in the past is to do something like create a file foo=2Eh that >looks >>> something like >>> >>> #include_next <foo=2Eh> >>> >>> #ifndev SOMETHING_NEW >>> #define SOMETHING_NEW 0 /* Or other values that are fail-safe on the >old >>> system */ >>> #endif >>> >>> and that's the change that needs to be made here=2E Sometimes, more >>> extensive things need to be done when the old library can't work at >all >>> with the new code=2E In those cases, the pattern is for foo=2Eh to >include >>> #define problem_fn my_problem_fn and then write a my_problem_fn that >wraps >>> problem_fn in a way that works on the old system=2E Kinda a poor man's >symbol >>> versioning, in a way (note: we can't use symbol version for this >since >>> we're building new binaries)=2E >>> >>> The "stop gap" gets things compiling, and maybe OK for the moment, >unless >>> the SOMETHING_NEW variable that's used (in this case FA_OPEN) causes >the >>> old library to do the wrong thing=2E I've not done the deep dive to >see if >>> this is the case or not=2E >>> >>> So, does that make sense? >>> >>> Warner >>> >> >> This solves one problem but what about the cases when a new krb5, >ntp, or >> amd is imported but fails to build because it is using the old >headers in >> /usr/include and linking against old libraries on the running system? >> >> These examples BTW have been fixed=2E My concern is there could be >other >> examples in contrib, yet to be discovered, that might also have the >same >> issues=2E >> > >That's the whole point if libegacy: to provide the glue that's needed >for >the bootstrap process=2E I'm surprised that ntp or amd are involved with >libegacy at all since they aren't bootstrap tools=2E Are you sure you >aren't >confusing two different problem domains? I know kerberos is, but it >kinda >needs to be=2E > >Warner Maybe I am conflating the two issues=2E I'll look again the next time I ge= t to a keyboard=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert <Cy=2ESchubert@cschubert=2Ecom> FreeBSD UNIX: <cy@FreeBSD=2Eorg> Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E From owner-svn-src-all@freebsd.org Tue Sep 3 14:07:58 2019 Return-Path: <owner-svn-src-all@freebsd.org> 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 898B3DD4AB; Tue, 3 Sep 2019 14:07:06 +0000 (UTC) (envelope-from yuripv@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 46N8096M8Zz4QDg; Tue, 3 Sep 2019 14:07:05 +0000 (UTC) (envelope-from yuripv@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1452) id 103311B091; Tue, 3 Sep 2019 14:06:28 +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 9305FE283; Thu, 18 Apr 2019 20:49:01 +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 331C28076B; Thu, 18 Apr 2019 20:49:00 +0000 (UTC) (envelope-from owner-src-committers@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 538) id 16483E22F; Thu, 18 Apr 2019 20:49:00 +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 2D4CEE22A for <src-committers@localmail.freebsd.org>; Thu, 18 Apr 2019 20:48:57 +0000 (UTC) (envelope-from cem@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D4C1D80766; Thu, 18 Apr 2019 20:48:56 +0000 (UTC) (envelope-from cem@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 915B7244CC; Thu, 18 Apr 2019 20:48:56 +0000 (UTC) (envelope-from cem@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id x3IKmutO073309; Thu, 18 Apr 2019 20:48:56 GMT (envelope-from cem@FreeBSD.org) Received: (from cem@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id x3IKmtG2073301; Thu, 18 Apr 2019 20:48:55 GMT (envelope-from cem@FreeBSD.org) Message-Id: <201904182048.x3IKmtG2073301@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: cem set sender to cem@FreeBSD.org using -f From: Conrad Meyer <cem@FreeBSD.org> To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r346358 - in head: . sys/dev/random sys/libkern sys/mips/conf sys/sys X-SVN-Group: head X-SVN-Commit-Author: cem X-SVN-Commit-Paths: in head: . sys/dev/random sys/libkern sys/mips/conf sys/sys X-SVN-Commit-Revision: 346358 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk X-Loop: FreeBSD.org Sender: owner-src-committers@freebsd.org X-Rspamd-Queue-Id: 331C28076B X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.96 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.96)[-0.959,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; 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" \)" <svn-src-all.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-all>, <mailto:svn-src-all-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-all/>; List-Post: <mailto:svn-src-all@freebsd.org> List-Help: <mailto:svn-src-all-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-all>, <mailto:svn-src-all-request@freebsd.org?subject=subscribe> Date: Tue, 03 Sep 2019 14:07:59 -0000 X-Original-Date: Thu, 18 Apr 2019 20:48:55 +0000 (UTC) X-List-Received-Date: Tue, 03 Sep 2019 14:07:59 -0000 Author: cem Date: Thu Apr 18 20:48:54 2019 New Revision: 346358 URL: https://svnweb.freebsd.org/changeset/base/346358 Log: random(4): Restore availability tradeoff prior to r346250 As discussed in that commit message, it is a dangerous default. But the safe default causes enough pain on a variety of platforms that for now, restore the prior default. Some of this is self-induced pain we should/could do better about; for example, programmatic CI systems and VM managers should introduce entropy from the host for individual VM instances. This is considered a future work item. On modern x86 and Power9 systems, this may be wholly unnecessary after D19928 lands (even in the non-ideal case where early /boot/entropy is unavailable), because they have fast hardware random sources available early in boot. But D19928 is not yet landed and we have a host of architectures which do not provide fast random sources. This change adds several tunables and diagnostic sysctls, documented thoroughly in UPDATING and sys/dev/random/random_infra.c. PR: 230875 (reopens) Reported by: adrian, jhb, imp, and probably others Reviewed by: delphij, imp (earlier version), markm (earlier version) Discussed with: adrian Approved by: secteam(delphij) Relnotes: yeah Security: related Differential Revision: https://reviews.freebsd.org/D19944 Modified: head/UPDATING head/sys/dev/random/random_infra.c head/sys/dev/random/randomdev.c head/sys/dev/random/randomdev.h head/sys/libkern/arc4random.c head/sys/mips/conf/PB92 head/sys/sys/param.h Modified: head/UPDATING ============================================================================== --- head/UPDATING Thu Apr 18 19:16:34 2019 (r346357) +++ head/UPDATING Thu Apr 18 20:48:54 2019 (r346358) @@ -31,6 +31,30 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW: disable the most expensive debugging functionality run "ln -s 'abort:false,junk:false' /etc/malloc.conf".) +20190418: + The following knobs have been added related to tradeoffs between + safe use of the random device and availability in the absence of + entropy: + + kern.random.initial_seeding.bypass_before_seeding: tunable; set + non-zero to bypass the random device prior to seeding, or zero to + block random requests until the random device is initially seeded. + For now, set to 1 (unsafe) by default to restore pre-r346250 boot + availability properties. + + kern.random.initial_seeding.read_random_bypassed_before_seeding: + read-only diagnostic sysctl that is set when bypass is enabled and + read_random(9) is bypassed, to enable programmatic handling of this + initial condition, if desired. + + kern.random.initial_seeding.arc4random_bypassed_before_seeding: + Similar to the above, but for for arc4random(9) initial seeding. + + kern.random.initial_seeding.disable_bypass_warnings: tunable; set + non-zero to disable warnings in dmesg when the same conditions are + met as for the diagnostic sysctls above. Defaults to zero, i.e., + produce warnings in dmesg when the conditions are met. + 20190416: The tunable "security.stack_protect.permit_nonrandom_cookies" may be set to a non-zero value to boot systems that do not provide early Modified: head/sys/dev/random/random_infra.c ============================================================================== --- head/sys/dev/random/random_infra.c Thu Apr 18 19:16:34 2019 (r346357) +++ head/sys/dev/random/random_infra.c Thu Apr 18 20:48:54 2019 (r346358) @@ -43,7 +43,61 @@ __FBSDID("$FreeBSD$"); #include <dev/random/randomdev.h> /* Set up the sysctl root node for the entropy device */ -SYSCTL_NODE(_kern, OID_AUTO, random, CTLFLAG_RW, 0, "Cryptographically Secure Random Number Generator"); +SYSCTL_NODE(_kern, OID_AUTO, random, CTLFLAG_RW, 0, + "Cryptographically Secure Random Number Generator"); +SYSCTL_NODE(_kern_random, OID_AUTO, initial_seeding, CTLFLAG_RW, 0, + "Initial seeding control and information"); + +/* + * N.B., this is a dangerous default, but it matches the behavior prior to + * r346250 (and, say, OpenBSD -- although they get some guaranteed saved + * entropy from the prior boot because of their KARL system, on RW media). + */ +bool random_bypass_before_seeding = true; +SYSCTL_BOOL(_kern_random_initial_seeding, OID_AUTO, + bypass_before_seeding, CTLFLAG_RDTUN, &random_bypass_before_seeding, + 0, "If set non-zero, bypass the random device in requests for random " + "data when the random device is not yet seeded. This is considered " + "dangerous. Ordinarily, the random device will block requests until " + "it is seeded by sufficient entropy."); + +/* + * This is a read-only diagnostic that reports the combination of the former + * tunable and actual bypass. It is intended for programmatic inspection by + * userspace administrative utilities after boot. + */ +bool read_random_bypassed_before_seeding = false; +SYSCTL_BOOL(_kern_random_initial_seeding, OID_AUTO, + read_random_bypassed_before_seeding, CTLFLAG_RD, + &read_random_bypassed_before_seeding, 0, "If non-zero, the random device " + "was bypassed because the 'bypass_before_seeding' knob was enabled and a " + "request was submitted prior to initial seeding."); + +/* + * This is a read-only diagnostic that reports the combination of the former + * tunable and actual bypass for arc4random initial seeding. It is intended + * for programmatic inspection by userspace administrative utilities after + * boot. + */ +bool arc4random_bypassed_before_seeding = false; +SYSCTL_BOOL(_kern_random_initial_seeding, OID_AUTO, + arc4random_bypassed_before_seeding, CTLFLAG_RD, + &arc4random_bypassed_before_seeding, 0, "If non-zero, the random device " + "was bypassed when initially seeding the kernel arc4random(9), because " + "the 'bypass_before_seeding' knob was enabled and a request was submitted " + "prior to initial seeding."); + +/* + * This knob is for users who do not want additional warnings in their logs + * because they intend to handle bypass by inspecting the status of the + * diagnostic sysctls. + */ +bool random_bypass_disable_warnings = false; +SYSCTL_BOOL(_kern_random_initial_seeding, OID_AUTO, + disable_bypass_warnings, CTLFLAG_RDTUN, + &random_bypass_disable_warnings, 0, "If non-zero, do not log a warning " + "if the 'bypass_before_seeding' knob is enabled and a request is " + "submitted prior to initial seeding."); MALLOC_DEFINE(M_ENTROPY, "entropy", "Entropy harvesting buffers and data structures"); Modified: head/sys/dev/random/randomdev.c ============================================================================== --- head/sys/dev/random/randomdev.c Thu Apr 18 19:16:34 2019 (r346357) +++ head/sys/dev/random/randomdev.c Thu Apr 18 20:48:54 2019 (r346358) @@ -236,11 +236,15 @@ READ_RANDOM_UIO(struct uio *uio, bool nonblock) } /*- - * Kernel API version of read_random(). - * This is similar to random_alg_read(), - * except it doesn't interface with uio(9). - * It cannot assumed that random_buf is a multiple of - * RANDOM_BLOCKSIZE bytes. + * Kernel API version of read_random(). This is similar to read_random_uio(), + * except it doesn't interface with uio(9). It cannot assumed that random_buf + * is a multiple of RANDOM_BLOCKSIZE bytes. + * + * If the tunable 'kern.random.initial_seeding.bypass_before_seeding' is set + * non-zero, silently fail to emit random data (matching the pre-r346250 + * behavior). If read_random is called prior to seeding and bypassed because + * of this tunable, the condition is reported in the read-only sysctl + * 'kern.random.initial_seeding.read_random_bypassed_before_seeding'. */ void READ_RANDOM(void *random_buf, u_int len) @@ -249,12 +253,31 @@ READ_RANDOM(void *random_buf, u_int len) KASSERT(random_buf != NULL, ("No suitable random buffer in %s", __func__)); p_random_alg_context->ra_pre_read(); + + if (len == 0) + return; + /* (Un)Blocking logic */ - if (!p_random_alg_context->ra_seeded()) + if (__predict_false(!p_random_alg_context->ra_seeded())) { + if (random_bypass_before_seeding) { + if (!read_random_bypassed_before_seeding) { + if (!random_bypass_disable_warnings) + printf("read_random: WARNING: bypassing" + " request for random data because " + "the random device is not yet " + "seeded and the knob " + "'bypass_before_seeding' was " + "enabled.\n"); + read_random_bypassed_before_seeding = true; + } + /* Avoid potentially leaking stack garbage */ + memset(random_buf, 0, len); + return; + } + (void)randomdev_wait_until_seeded(SEEDWAIT_UNINTERRUPTIBLE); + } read_rate_increment(roundup2(len, sizeof(uint32_t))); - if (len == 0) - return; /* * The underlying generator expects multiples of * RANDOM_BLOCKSIZE. Modified: head/sys/dev/random/randomdev.h ============================================================================== --- head/sys/dev/random/randomdev.h Thu Apr 18 19:16:34 2019 (r346357) +++ head/sys/dev/random/randomdev.h Thu Apr 18 20:48:54 2019 (r346358) @@ -37,6 +37,7 @@ #ifdef SYSCTL_DECL /* from sysctl.h */ SYSCTL_DECL(_kern_random); +SYSCTL_DECL(_kern_random_initial_seeding); #define RANDOM_CHECK_UINT(name, min, max) \ static int \ @@ -54,6 +55,11 @@ random_check_uint_##name(SYSCTL_HANDLER_ARGS) \ #endif /* SYSCTL_DECL */ MALLOC_DECLARE(M_ENTROPY); + +extern bool random_bypass_before_seeding; +extern bool read_random_bypassed_before_seeding; +extern bool arc4random_bypassed_before_seeding; +extern bool random_bypass_disable_warnings; #endif /* _KERNEL */ Modified: head/sys/libkern/arc4random.c ============================================================================== --- head/sys/libkern/arc4random.c Thu Apr 18 19:16:34 2019 (r346357) +++ head/sys/libkern/arc4random.c Thu Apr 18 20:48:54 2019 (r346358) @@ -41,6 +41,9 @@ __FBSDID("$FreeBSD$"); #include <sys/time.h> #include <crypto/chacha20/chacha.h> +#include <crypto/sha2/sha256.h> +#include <dev/random/randomdev.h> +#include <machine/cpu.h> #define CHACHA20_RESEED_BYTES 65536 #define CHACHA20_RESEED_SECONDS 300 @@ -77,12 +80,43 @@ chacha20_randomstir(struct chacha20_s *chacha20) struct timeval tv_now; u_int8_t key[CHACHA20_KEYBYTES]; - /* - * If the loader(8) did not have an entropy stash from the previous - * shutdown to load, then we will block. The answer is to make sure - * there is an entropy stash at shutdown time. - */ - read_random(key, CHACHA20_KEYBYTES); + if (__predict_false(random_bypass_before_seeding && !is_random_seeded())) { + SHA256_CTX ctx; + uint64_t cc; + uint32_t fver; + + if (!arc4random_bypassed_before_seeding) { + arc4random_bypassed_before_seeding = true; + if (!random_bypass_disable_warnings) + printf("arc4random: WARNING: initial seeding " + "bypassed the cryptographic random device " + "because it was not yet seeded and the " + "knob 'bypass_before_seeding' was " + "enabled.\n"); + } + + /* Last ditch effort to inject something in a bad condition. */ + cc = get_cyclecount(); + SHA256_Init(&ctx); + SHA256_Update(&ctx, key, sizeof(key)); + SHA256_Update(&ctx, &cc, sizeof(cc)); + fver = __FreeBSD_version; + SHA256_Update(&ctx, &fver, sizeof(fver)); + _Static_assert(sizeof(key) == SHA256_DIGEST_LENGTH, + "make sure 256 bits is still 256 bits"); + SHA256_Final(key, &ctx); + } else { + /* + * If the loader(8) did not have an entropy stash from the + * previous shutdown to load, then we will block. The answer is + * to make sure there is an entropy stash at shutdown time. + * + * On the other hand, if the random_bypass_before_seeding knob + * was set and we landed in this branch, we know this won't + * block because we know the random device is seeded. + */ + read_random(key, CHACHA20_KEYBYTES); + } getmicrouptime(&tv_now); mtx_lock(&chacha20->mtx); chacha_keysetup(&chacha20->ctx, key, CHACHA20_KEYBYTES*8); Modified: head/sys/mips/conf/PB92 ============================================================================== --- head/sys/mips/conf/PB92 Thu Apr 18 19:16:34 2019 (r346357) +++ head/sys/mips/conf/PB92 Thu Apr 18 20:48:54 2019 (r346358) @@ -133,5 +133,5 @@ device loop device ether #device md #device bpf -#device random +device random #device if_bridge Modified: head/sys/sys/param.h ============================================================================== --- head/sys/sys/param.h Thu Apr 18 19:16:34 2019 (r346357) +++ head/sys/sys/param.h Thu Apr 18 20:48:54 2019 (r346358) @@ -60,7 +60,7 @@ * in the range 5 to 9. */ #undef __FreeBSD_version -#define __FreeBSD_version 1300019 /* Master, propagated to newvers */ +#define __FreeBSD_version 1300020 /* Master, propagated to newvers */ /* * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD,
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E54A972-27CE-498F-B0B9-B65A6E87F213>