From owner-freebsd-arch@FreeBSD.ORG Sun Aug 4 13:47:01 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 64CAEF29 for ; Sun, 4 Aug 2013 13:47:01 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2AA3A29A1 for ; Sun, 4 Aug 2013 13:47:01 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 9E6D43592EA for ; Sun, 4 Aug 2013 15:46:58 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 73F2F28494; Sun, 4 Aug 2013 15:46:58 +0200 (CEST) Date: Sun, 4 Aug 2013 15:46:58 +0200 From: Jilles Tjoelker To: freebsd-arch@freebsd.org Subject: Reliable process tracking Message-ID: <20130804134658.GC35080@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 13:47:01 -0000 When shutting down a service or requesting status, rc.subr currently uses a combination of pidfiles and process names. This is fairly but not completely reliable once it is set up correctly (which can take a lot of work and possibly patching the daemon to use pidfile(3) from our libutil). It is also incapable of killing multiprocess daemons such as CGI web servers without cooperation of the daemon. I think what is needed here is a facility that marks a process and all of its descendants. Removing the mark should be a privileged or at least an unusual operation; no unprivileged function specified by POSIX such as setsid() should do this. There is no such facility in POSIX, but there are some FreeBSD-specific facilities that come close: * Do the tracking in userland using kqueue EVFILT_PROC NOTE_TRACK. I think this does not work because there is no way to deal with NOTE_TRACKERR. NOTE_TRACKERR could perhaps be avoided by making fork() fail instead but that may be rather nasty if the tracking process does not call kevent() while many tracked processes are created and destroyed again. * Jails. If there were a way to put a process in jail without affecting its privileges, filesystem root directory and network interfaces, this would be usable. Processes cannot escape from a jail and there are ways to signal all processes in a jail or to terminate forcibly all processes in a jail. * setloginclass(2). The login class attribute cannot be changed by a normal user, although login(1) and su(1) will change it to the target user's class. The rctl system is also available to limit resources based on login class; this can also be useful to kill all processes with some login class without racing with fork(). * setlogin(2). Everything except setuid login(1) knows to be careful with this, but breaking getlogin(2) seems unwise. Therefore, this is only useful for daemons with one passwd line per instance. Similar facilities in other operating systems: Linux cgroups, Solaris process contracts. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Sun Aug 4 13:58:27 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DC9D51DA; Sun, 4 Aug 2013 13:58:27 +0000 (UTC) (envelope-from prvs=1928f37ee5=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58ABF29FF; Sun, 4 Aug 2013 13:58:26 +0000 (UTC) Received: from r2d2 ([82.69.141.170]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50005326170.msg; Sun, 04 Aug 2013 14:58:24 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sun, 04 Aug 2013 14:58:24 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 82.69.141.170 X-Return-Path: prvs=1928f37ee5=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <1A44B776F5B64F7494C52060B5B9ED73@multiplay.co.uk> From: "Steven Hartland" To: "Andriy Gapon" References: <51F67B2A.3040302@FreeBSD.org> <69CEF0CC3C8C4B9BBA8E3ACACB18DC2B@multiplay.co.uk> <51F6B5EF.5020407@FreeBSD.org> Subject: Re: translate INVARIANTS to DEBUG for code from OpenSolaris Date: Sun, 4 Aug 2013 14:59:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 13:58:27 -0000 ----- Original Message ----- From: "Andriy Gapon" >> I'm not sure you need #define ZFS_DEBUG as its already a dependency on >> DEBUG see: >> sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zfs_debug.h > > Good point. Thank you. > >> Should this connection be broken and INVARIANTS only trigger DEBUG by >> default? One potential reason for this distinction is that ZFS_DEBUG brings >> with it some potentially quite heavy weight validation such as dnode_verify. >> >> If so I have small list of additional fixes here that where required when >> I tested enabling ASSERTS checking without ZFS_DEBUG. >> >> What do others think, should INVARIANTS trigger ZFS_DEBUG or should that >> be kept seperate? > > I would prefer to follow what upstream does in this respect. > If DEBUG implies ZFS_DEBUG upstream, then I think that we should do the same for > INVARIANTS -> DEBUG -> ZFS_DEBUG. > Unless there are strong reasons to do otherwise. Been testing this today including forcing a ZFS ASSERT violation and it all works as expected including not getting all the false positive LOR :) Do intend to get this committed in the near future? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-arch@FreeBSD.ORG Sun Aug 4 14:27:22 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A8B6B6ED for ; Sun, 4 Aug 2013 14:27:22 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by mx1.freebsd.org (Postfix) with ESMTP id 8DE6C2AFB for ; Sun, 4 Aug 2013 14:27:22 +0000 (UTC) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by hapkido.dreamhost.com (Postfix) with ESMTP id C0AC2DD81C for ; Sun, 4 Aug 2013 07:27:16 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id E57DD35005B for ; Sun, 4 Aug 2013 07:27:09 -0700 (PDT) Received: from lab (ip72-219-240-45.dc.dc.cox.net [72.219.240.45]) (Authenticated sender: trhodes@fbsdsecure.org) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPA id AA2F9350058 for ; Sun, 4 Aug 2013 07:27:09 -0700 (PDT) Date: Sun, 4 Aug 2013 10:27:08 -0400 From: Tom Rhodes To: freebsd-arch@freebsd.org Subject: Re: Reliable process tracking Message-Id: <20130804102708.36341a8a.trhodes@FreeBSD.org> In-Reply-To: <20130804134658.GC35080@stack.nl> References: <20130804134658.GC35080@stack.nl> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 14:27:22 -0000 On Sun, 4 Aug 2013 15:46:58 +0200 Jilles Tjoelker wrote: > When shutting down a service or requesting status, rc.subr currently > uses a combination of pidfiles and process names. This is fairly but not > completely reliable once it is set up correctly (which can take a lot of > work and possibly patching the daemon to use pidfile(3) from our > libutil). It is also incapable of killing multiprocess daemons such as > CGI web servers without cooperation of the daemon. > > I think what is needed here is a facility that marks a process and all > of its descendants. Removing the mark should be a privileged or at least > an unusual operation; no unprivileged function specified by POSIX such > as setsid() should do this. > > There is no such facility in POSIX, but there are some FreeBSD-specific > facilities that come close: > > * Do the tracking in userland using kqueue EVFILT_PROC NOTE_TRACK. I > think this does not work because there is no way to deal with > NOTE_TRACKERR. NOTE_TRACKERR could perhaps be avoided by making fork() > fail instead but that may be rather nasty if the tracking process does > not call kevent() while many tracked processes are created and > destroyed again. > > * Jails. If there were a way to put a process in jail without affecting > its privileges, filesystem root directory and network interfaces, this > would be usable. Processes cannot escape from a jail and there are > ways to signal all processes in a jail or to terminate forcibly all > processes in a jail. > > * setloginclass(2). The login class attribute cannot be changed by a > normal user, although login(1) and su(1) will change it to the > target user's class. The rctl system is also available to limit > resources based on login class; this can also be useful to kill all > processes with some login class without racing with fork(). > > * setlogin(2). Everything except setuid login(1) knows to be careful > with this, but breaking getlogin(2) seems unwise. Therefore, this is > only useful for daemons with one passwd line per instance. > > Similar facilities in other operating systems: Linux cgroups, Solaris > process contracts. There is fscd - it does a lot of what you ask for. In fact, I had talked to a few people about bringing it into base but have not really figured out how I want to integrate it into rc. -- Tom Rhodes From owner-freebsd-arch@FreeBSD.ORG Sun Aug 4 16:49:56 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 356FDB3F; Sun, 4 Aug 2013 16:49:56 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF2E82F69; Sun, 4 Aug 2013 16:49:55 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id A81FE3592EA; Sun, 4 Aug 2013 18:49:54 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 835A028494; Sun, 4 Aug 2013 18:49:54 +0200 (CEST) Date: Sun, 4 Aug 2013 18:49:54 +0200 From: Jilles Tjoelker To: Tom Rhodes Subject: Re: Reliable process tracking Message-ID: <20130804164954.GA37887@stack.nl> References: <20130804134658.GC35080@stack.nl> <20130804102708.36341a8a.trhodes@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130804102708.36341a8a.trhodes@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 16:49:56 -0000 On Sun, Aug 04, 2013 at 10:27:08AM -0400, Tom Rhodes wrote: > On Sun, 4 Aug 2013 15:46:58 +0200 > Jilles Tjoelker wrote: > > When shutting down a service or requesting status, rc.subr currently > > uses a combination of pidfiles and process names. This is fairly but not > > completely reliable once it is set up correctly (which can take a lot of > > work and possibly patching the daemon to use pidfile(3) from our > > libutil). It is also incapable of killing multiprocess daemons such as > > CGI web servers without cooperation of the daemon. > > I think what is needed here is a facility that marks a process and all > > of its descendants. Removing the mark should be a privileged or at least > > an unusual operation; no unprivileged function specified by POSIX such > > as setsid() should do this. > > [snip] > > Similar facilities in other operating systems: Linux cgroups, Solaris > > process contracts. > There is fscd - it does a lot of what you ask for. In fact, I had > talked to a few people about bringing it into base but have not > really figured out how I want to integrate it into rc. I think fscd complements reliable process tracking; it does not provide it. Fscd relies on rc.d's status, stop and restart to work and therefore only works properly if those work properly. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Sun Aug 4 17:15:52 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 58A70175 for ; Sun, 4 Aug 2013 17:15:52 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 373492074 for ; Sun, 4 Aug 2013 17:15:51 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r74HFlLB050322; Sun, 4 Aug 2013 17:15:47 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id ryppdiwnp2k5wgqnayac494zy2; Sun, 04 Aug 2013 17:15:47 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Reliable process tracking Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: <20130804134658.GC35080@stack.nl> Date: Sun, 4 Aug 2013 10:15:47 -0700 Content-Transfer-Encoding: 7bit Message-Id: <37E22E4B-4710-42DB-AF82-1F4AF26D6005@kientzle.com> References: <20130804134658.GC35080@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1283) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 17:15:52 -0000 On Aug 4, 2013, at 6:46 AM, Jilles Tjoelker wrote: > When shutting down a service or requesting status, rc.subr currently > uses a combination of pidfiles and process names. This is fairly but not > completely reliable once it is set up correctly (which can take a lot of > work and possibly patching the daemon to use pidfile(3) from our > libutil). It is also incapable of killing multiprocess daemons such as > CGI web servers without cooperation of the daemon. > > I think what is needed here is a facility that marks a process and all > of its descendants. It sounds like all you really need is some way to signal a process and all descendants. Why do you need to actively mark and/or track them? Tim From owner-freebsd-arch@FreeBSD.ORG Sun Aug 4 19:53:32 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0901C694 for ; Sun, 4 Aug 2013 19:53:32 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C3DA42736 for ; Sun, 4 Aug 2013 19:53:31 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id D0E621203D9; Sun, 4 Aug 2013 21:53:16 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id BA6CD28494; Sun, 4 Aug 2013 21:53:16 +0200 (CEST) Date: Sun, 4 Aug 2013 21:53:16 +0200 From: Jilles Tjoelker To: Tim Kientzle Subject: Re: Reliable process tracking Message-ID: <20130804195316.GA39246@stack.nl> References: <20130804134658.GC35080@stack.nl> <37E22E4B-4710-42DB-AF82-1F4AF26D6005@kientzle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37E22E4B-4710-42DB-AF82-1F4AF26D6005@kientzle.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 19:53:32 -0000 On Sun, Aug 04, 2013 at 10:15:47AM -0700, Tim Kientzle wrote: > On Aug 4, 2013, at 6:46 AM, Jilles Tjoelker wrote: > > When shutting down a service or requesting status, rc.subr currently > > uses a combination of pidfiles and process names. This is fairly but not > > completely reliable once it is set up correctly (which can take a lot of > > work and possibly patching the daemon to use pidfile(3) from our > > libutil). It is also incapable of killing multiprocess daemons such as > > CGI web servers without cooperation of the daemon. > > I think what is needed here is a facility that marks a process and all > > of its descendants. > It sounds like all you really need is some way to > signal a process and all descendants. No, it is different in several ways. Firstly, you need a different definition of descendants than the one implied by getppid(). The parent process ID resets to 1 when the parent exits, which would cause the child to lose its relationship with the group. Secondly, I want to keep track of the group even if the top level process terminates. For example, if apache's or postgres's master process crashes, I want to shut down all remaining worker processes before attempting to start a new master. > Why do you need to actively mark and/or track them? Tracking is needed for restarting services when they crash, as done by fsc. It can also be useful for providing information to the system administrator. Also, it can be useful for legacy/simple compatibility. After running '/etc/rc.d/foo start' with a mark, the marked process(es) with ppid 1 can be considered the processes that need to be monitored for service foo. Admittedly, this is not fully reliable, but it is better than matching by name on the process table (which is otherwise needed if the daemon does not write a pid file). -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Sun Aug 4 20:10:31 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 044FBF34 for ; Sun, 4 Aug 2013 20:10:31 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 34B4F2827 for ; Sun, 4 Aug 2013 20:10:29 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA12000; Sun, 04 Aug 2013 23:10:27 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V64dH-000Awf-Gl; Sun, 04 Aug 2013 23:10:27 +0300 Message-ID: <51FEB519.8010600@FreeBSD.org> Date: Sun, 04 Aug 2013 23:10:01 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Steven Hartland Subject: Re: translate INVARIANTS to DEBUG for code from OpenSolaris References: <51F67B2A.3040302@FreeBSD.org> <69CEF0CC3C8C4B9BBA8E3ACACB18DC2B@multiplay.co.uk> <51F6B5EF.5020407@FreeBSD.org> <1A44B776F5B64F7494C52060B5B9ED73@multiplay.co.uk> In-Reply-To: <1A44B776F5B64F7494C52060B5B9ED73@multiplay.co.uk> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 20:10:31 -0000 on 04/08/2013 16:59 Steven Hartland said the following: > Been testing this today including forcing a ZFS ASSERT violation and it > all works as expected including not getting all the false positive LOR :) Thank you for giving it a spin! > Do intend to get this committed in the near future? Yes. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Sun Aug 4 20:28:25 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 19B6A48B; Sun, 4 Aug 2013 20:28:25 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D1F5F28CC; Sun, 4 Aug 2013 20:28:24 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 742F23592E1; Sun, 4 Aug 2013 22:28:23 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 516B528494; Sun, 4 Aug 2013 22:28:23 +0200 (CEST) Date: Sun, 4 Aug 2013 22:28:23 +0200 From: Jilles Tjoelker To: Andriy Gapon Subject: Re: amd64: -O2 even with DEBUG Message-ID: <20130804202823.GB39246@stack.nl> References: <51F221D4.8040308@FreeBSD.org> <20130726185425.GS26412@funkthat.com> <51F37578.2080405@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51F37578.2080405@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 20:28:25 -0000 On Sat, Jul 27, 2013 at 10:23:36AM +0300, Andriy Gapon wrote: > on 26/07/2013 21:54 John-Mark Gurney said the following: > > Andriy Gapon wrote this message on Fri, Jul 26, 2013 at 10:14 +0300: > >> I wonder why amd64 is distinguished to have -O2 in COPTFLAGS even > >> when DEBUG is defined. For all other archs it's -O for that case. > >> Perhaps, this was discussed / explained in the past, but I would > >> appreciate it being said again (or even written as a comment in > >> kern.pre.mk). > > It's probably because at least gcc produces terrible amd64 code w/o > > it... It will constantly reload the register it uses to do relative > > loads w/ the same value even though nothing changed... makes > > performance suck... > Well, we are talking about the DEBUG case. So I am not sure if better > performance has more importance than better debugging. And I believe > that -O2 does make debugging harder. On the other hand, the difference between DEBUG and !DEBUG should be minimized to avoid heisenbugs and taking advantage of undefined behaviour that does not work at -O2. Also note that most standard kernel configuration files have the line makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols which suggests that it only adds debug symbols and does not lower the optimization level (even though that is only the case on amd64). So it seems you are asking about lowering the optimization level of almost all amd64 kernels (there seems little reason not to generate .symbols files). In my experience, debugging -O2 code is usually possible with experience, knowledge about compiler optimizations and good compilers and debuggers (for example, gcc and gdb were improved in this area after the switch to GPLv3). It can be rather annoying, though, if there is a lot of inlining or the value of the variable you need is not available (the value may be available elsewhere in the call chain or not at all). -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Mon Aug 5 03:44:10 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8F5F0BAD; Mon, 5 Aug 2013 03:44:10 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7C934260F; Mon, 5 Aug 2013 03:44:10 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 5250C1A3C1C; Sun, 4 Aug 2013 20:44:04 -0700 (PDT) Message-ID: <51FF1F82.5050100@freebsd.org> Date: Sun, 04 Aug 2013 20:44:02 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jilles Tjoelker Subject: Re: Reliable process tracking References: <20130804134658.GC35080@stack.nl> <20130804102708.36341a8a.trhodes@FreeBSD.org> <20130804164954.GA37887@stack.nl> In-Reply-To: <20130804164954.GA37887@stack.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tom Rhodes , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 03:44:10 -0000 On 8/4/13 9:49 AM, Jilles Tjoelker wrote: > On Sun, Aug 04, 2013 at 10:27:08AM -0400, Tom Rhodes wrote: >> On Sun, 4 Aug 2013 15:46:58 +0200 >> Jilles Tjoelker wrote: >>> When shutting down a service or requesting status, rc.subr currently >>> uses a combination of pidfiles and process names. This is fairly but not >>> completely reliable once it is set up correctly (which can take a lot of >>> work and possibly patching the daemon to use pidfile(3) from our >>> libutil). It is also incapable of killing multiprocess daemons such as >>> CGI web servers without cooperation of the daemon. >>> I think what is needed here is a facility that marks a process and all >>> of its descendants. Removing the mark should be a privileged or at least >>> an unusual operation; no unprivileged function specified by POSIX such >>> as setsid() should do this. >>> [snip] >>> Similar facilities in other operating systems: Linux cgroups, Solaris >>> process contracts. >> There is fscd - it does a lot of what you ask for. In fact, I had >> talked to a few people about bringing it into base but have not >> really figured out how I want to integrate it into rc. > I think fscd complements reliable process tracking; it does not provide > it. Fscd relies on rc.d's status, stop and restart to work and therefore > only works properly if those work properly. > Jilles, very exciting you are looking into this. Have you evaluated Linux's "cgroup" facility? From what I understand, it is a superset of your needs, so maybe taking some parts of it may help? http://en.wikipedia.org/wiki/Cgroups From owner-freebsd-arch@FreeBSD.ORG Mon Aug 5 07:05:15 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4AF786CD for ; Mon, 5 Aug 2013 07:05:15 +0000 (UTC) (envelope-from phk@phk.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 127CE2BF9 for ; Mon, 5 Aug 2013 07:05:15 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id ABACB3EB33 for ; Mon, 5 Aug 2013 07:05:07 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.7/8.14.7) with ESMTP id r75757Ok041765 for ; Mon, 5 Aug 2013 07:05:07 GMT (envelope-from phk@phk.freebsd.dk) To: arch@freebsd.org Subject: sockaddr API question From: Poul-Henning Kamp Content-Type: text/plain; charset=ISO-8859-1 Date: Mon, 05 Aug 2013 07:05:07 +0000 Message-ID: <41764.1375686307@critter.freebsd.dk> X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 07:05:15 -0000 The theoretical variant of the question: Where the length of a sockaddr must be passed to an API, library or kernel, is it _always_ legal for the length to be larger than the relevant subtype of struct sockaddr ? The practical variant of the question: Can I just use struct sockaddr_storage all over the place and give sizeof(struct sockaddr_storage) to sockaddr_len arguments ? PS: Yes, I realize that there will be inefficiencies related to moving more data than required, the question is only if it is safe, not if it is a good idea. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@FreeBSD.ORG Mon Aug 5 10:49:55 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9AAEA9AF; Mon, 5 Aug 2013 10:49:55 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D0E152474; Mon, 5 Aug 2013 10:49:54 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id c50so1543708eek.4 for ; Mon, 05 Aug 2013 03:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=HoKkMFwZVoJZDvBP/+q5zEdmFCZD/m/BaoGI3CHureA=; b=USroDzI/HDnRhCnkCz8lw8uQimxIB8+f9HO7nH6HiWIKQIpSjgylbQ/zQmFA5VW7uI o/MiYCnQzkUYhGQNsR3uz43flYf66PLtrhZRkDF4kKASPIjVeyL9zrtRw0IVTU/t9Wsd 1CybmXxiYJoeYc5s9u8T88uRgpOooNI+lNosoHcAzbOBR5hUWT2nHRKgujWzOSFBm8rc US+Mpoo3mz3+GhCBJha1PeGhxhgtA4DAwhWtFAYj9pi6Ntc86Td5ytR/IwBKcbsam10R 7bLxPZfyCh+rzaEcr9C7XrVSj4kKG430viAwC/Jjy8qsqYWN8NiWcUDBR7gYi4g6TUvF eFPA== X-Received: by 10.15.41.77 with SMTP id r53mr16335074eev.64.1375699793075; Mon, 05 Aug 2013 03:49:53 -0700 (PDT) Received: from [192.168.1.4] (aac168.neoplus.adsl.tpnet.pl. [83.25.2.168]) by mx.google.com with ESMTPSA id bn13sm2721029eeb.11.2013.08.05.03.49.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 03:49:52 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Reliable process tracking From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <51FF1F82.5050100@freebsd.org> Date: Mon, 5 Aug 2013 12:49:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6B52B01A-5CEC-41BC-9B59-57BD46CAE9B2@FreeBSD.org> References: <20130804134658.GC35080@stack.nl> <20130804102708.36341a8a.trhodes@FreeBSD.org> <20130804164954.GA37887@stack.nl> <51FF1F82.5050100@freebsd.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1508) Cc: Tom Rhodes , Jilles Tjoelker , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 10:49:55 -0000 Wiadomo=B6=E6 napisana przez Alfred Perlstein w = dniu 5 sie 2013, o godz. 05:44: > On 8/4/13 9:49 AM, Jilles Tjoelker wrote: >> On Sun, Aug 04, 2013 at 10:27:08AM -0400, Tom Rhodes wrote: >>> On Sun, 4 Aug 2013 15:46:58 +0200 >>> Jilles Tjoelker wrote: >>>> When shutting down a service or requesting status, rc.subr = currently >>>> uses a combination of pidfiles and process names. This is fairly = but not >>>> completely reliable once it is set up correctly (which can take a = lot of >>>> work and possibly patching the daemon to use pidfile(3) from our >>>> libutil). It is also incapable of killing multiprocess daemons such = as >>>> CGI web servers without cooperation of the daemon. >>>> I think what is needed here is a facility that marks a process and = all >>>> of its descendants. Removing the mark should be a privileged or at = least >>>> an unusual operation; no unprivileged function specified by POSIX = such >>>> as setsid() should do this. >>>> [snip] >>>> Similar facilities in other operating systems: Linux cgroups, = Solaris >>>> process contracts. >>> There is fscd - it does a lot of what you ask for. In fact, I had >>> talked to a few people about bringing it into base but have not >>> really figured out how I want to integrate it into rc. >> I think fscd complements reliable process tracking; it does not = provide >> it. Fscd relies on rc.d's status, stop and restart to work and = therefore >> only works properly if those work properly. >>=20 > Jilles, very exciting you are looking into this. Have you evaluated = Linux's "cgroup" facility? =46rom what I understand, it is a superset = of your needs, so maybe taking some parts of it may help? The good parts of cgroups were already implemented as setloginclass(2) = :-) From owner-freebsd-arch@FreeBSD.ORG Mon Aug 5 11:13:15 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 58A499C2 for ; Mon, 5 Aug 2013 11:13:15 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DE31F2785 for ; Mon, 5 Aug 2013 11:13:14 +0000 (UTC) Received: by mail-ea0-f178.google.com with SMTP id a15so1572073eae.9 for ; Mon, 05 Aug 2013 04:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=aPWBKWhEpyzrKXEQqoZOV1K91Cw72HDaYY/XqsaB1y8=; b=0UGiz4Vp906tbY9lHtu/zTL2TdNZ+o9EzwawhdwIwfu9x1eODH2sYqgb3SJGMbyYrM xFICP84gDAS5NrdPlnb8G3DQW7Di694VcIQ+h38o6MyywEn9+AYjsBmyXVuDBxOPVJA9 tUj67qrJi7vzLQVSGmqBSsVX3OCl/9CI444btfsqMoOXgm2ltk6CRU5+d/ne0cGmIZ3D qD3m7PmVEXUT7tZWYMUJd8UgVTyktxycsWsP8XNS3/vkz2/FAM0AklftffGDlI2QCLXc y2ubYAfe/8ya4dFBhj+MOaQ8nyXuD4myHN+oXwegmMFT5eHM2PG9fadHf+F2Pkhv3FCP SQKA== X-Received: by 10.14.184.4 with SMTP id r4mr16532290eem.100.1375701193127; Mon, 05 Aug 2013 04:13:13 -0700 (PDT) Received: from [192.168.1.4] (aac168.neoplus.adsl.tpnet.pl. [83.25.2.168]) by mx.google.com with ESMTPSA id cg12sm32535522eeb.7.2013.08.05.04.13.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 04:13:12 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Reliable process tracking From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <20130804134658.GC35080@stack.nl> Date: Mon, 5 Aug 2013 13:13:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130804134658.GC35080@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1508) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 11:13:15 -0000 Wiadomo=B6=E6 napisana przez Jilles Tjoelker w dniu 4 = sie 2013, o godz. 15:46: > When shutting down a service or requesting status, rc.subr currently > uses a combination of pidfiles and process names. This is fairly but = not > completely reliable once it is set up correctly (which can take a lot = of > work and possibly patching the daemon to use pidfile(3) from our > libutil). It is also incapable of killing multiprocess daemons such as > CGI web servers without cooperation of the daemon. >=20 > I think what is needed here is a facility that marks a process and all > of its descendants. Removing the mark should be a privileged or at = least > an unusual operation; no unprivileged function specified by POSIX such > as setsid() should do this. I've actually thought about that when I added setloginclass(2). It's = trivial to modify rc.subr to use su(8) to set login class for each service. It = should be trivial to modify pkill(1) and killall(1) to add "-c" option to kill = all processes in a given login class. Two caveats: 1. Login classes, just like UIDs, are global, not per jail. This means = when you want to kill all processees in a login class, you should probably = use "-j" option to limit it to a given jail, e.g. jail 0. 2. I'm not sure if pkill(1) has any special way of handling this, but = there is an obvious race condition between iterating over processes in = userland in pkill(1) and quickly forking processes to kill. Perhaps we should = have some kind of syscall to do it in a race-free way? From owner-freebsd-arch@FreeBSD.ORG Mon Aug 5 11:54:25 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B9EDB575 for ; Mon, 5 Aug 2013 11:54:25 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4C59B2925 for ; Mon, 5 Aug 2013 11:54:25 +0000 (UTC) Received: by mail-ea0-f175.google.com with SMTP id m14so1549266eaj.20 for ; Mon, 05 Aug 2013 04:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=3O7QO2VxPpyqJCQnvabLY8nRhpYX7SQsB1CEOgNQrcw=; b=LBrwEmt6EjjlQP3SHIndI8O7bwXm9x2tYfdC/fsaK1VrqO1yBgIVMzKBQ6okyBzN67 U7LUnPfPOjZST/SOCUAKWKCr9IVIQu4id3arlf7PXxJexL5hYWHcd8XqvVkqoj3ACCzy w+TmETkg1uaVeuNVC/oURbEAGTz4PWwy/36qfkInoUePkSez8kXAm/b4u2/lylREhjhu BTSHoyBQHcBXIm1M0pNwHiwASEGnOXRoPst3xA0evMufRY3AowFkuWqBQYOvWLtNgMbu vH7WurfMGIHFsxn095bEKTNZj8k5po+PLq6qbinrEKhAezFE9jvjO6DDg00QEoKeNm78 blRg== X-Received: by 10.14.110.9 with SMTP id t9mr16817491eeg.115.1375703663661; Mon, 05 Aug 2013 04:54:23 -0700 (PDT) Received: from [192.168.1.4] (aac168.neoplus.adsl.tpnet.pl. [83.25.2.168]) by mx.google.com with ESMTPSA id k3sm32755249een.16.2013.08.05.04.54.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 05 Aug 2013 04:54:22 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Reliable process tracking From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: Date: Mon, 5 Aug 2013 13:54:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <014C9BBF-E651-48B9-9F42-7849BE292B5A@FreeBSD.org> References: <20130804134658.GC35080@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1508) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 11:54:25 -0000 Wiadomo=B6=E6 napisana przez Edward Tomasz Napiera=B3a = w dniu 5 sie 2013, o godz. 13:13: > Wiadomo=B6=E6 napisana przez Jilles Tjoelker w dniu = 4 sie 2013, o godz. 15:46: >> When shutting down a service or requesting status, rc.subr currently >> uses a combination of pidfiles and process names. This is fairly but = not >> completely reliable once it is set up correctly (which can take a lot = of >> work and possibly patching the daemon to use pidfile(3) from our >> libutil). It is also incapable of killing multiprocess daemons such = as >> CGI web servers without cooperation of the daemon. >>=20 >> I think what is needed here is a facility that marks a process and = all >> of its descendants. Removing the mark should be a privileged or at = least >> an unusual operation; no unprivileged function specified by POSIX = such >> as setsid() should do this. >=20 > I've actually thought about that when I added setloginclass(2). It's = trivial > to modify rc.subr to use su(8) to set login class for each service. = It should > be trivial to modify pkill(1) and killall(1) to add "-c" option to = kill all processes > in a given login class And here is the patch: http://people.freebsd.org/~trasz/pkill-c.diff From owner-freebsd-arch@FreeBSD.ORG Mon Aug 5 13:46:22 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D38C3771 for ; Mon, 5 Aug 2013 13:46:22 +0000 (UTC) (envelope-from trhodes@FreeBSD.org) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by mx1.freebsd.org (Postfix) with ESMTP id B968E2E19 for ; Mon, 5 Aug 2013 13:46:22 +0000 (UTC) Received: from homiemail-a98.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by hapkido.dreamhost.com (Postfix) with ESMTP id 37923DD560 for ; Mon, 5 Aug 2013 06:46:22 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id 5E50F2C2060; Mon, 5 Aug 2013 06:46:16 -0700 (PDT) Received: from lab (ip72-219-240-45.dc.dc.cox.net [72.219.240.45]) (Authenticated sender: trhodes@fbsdsecure.org) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPA id 006172C2057; Mon, 5 Aug 2013 06:46:15 -0700 (PDT) Date: Mon, 5 Aug 2013 09:46:14 -0400 From: Tom Rhodes To: Jilles Tjoelker Subject: Re: Reliable process tracking Message-Id: <20130805094614.3ff8c2fa.trhodes@FreeBSD.org> In-Reply-To: <20130804195316.GA39246@stack.nl> References: <20130804134658.GC35080@stack.nl> <37E22E4B-4710-42DB-AF82-1F4AF26D6005@kientzle.com> <20130804195316.GA39246@stack.nl> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: tim@kientzle.com, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Aug 2013 13:46:22 -0000 On Sun, 4 Aug 2013 21:53:16 +0200 Jilles Tjoelker wrote: > On Sun, Aug 04, 2013 at 10:15:47AM -0700, Tim Kientzle wrote: > > On Aug 4, 2013, at 6:46 AM, Jilles Tjoelker wrote: > > > When shutting down a service or requesting status, rc.subr currently > > > uses a combination of pidfiles and process names. This is fairly but not > > > completely reliable once it is set up correctly (which can take a lot of > > > work and possibly patching the daemon to use pidfile(3) from our > > > libutil). It is also incapable of killing multiprocess daemons such as > > > CGI web servers without cooperation of the daemon. > > > > I think what is needed here is a facility that marks a process and all > > > of its descendants. > > > It sounds like all you really need is some way to > > signal a process and all descendants. > > No, it is different in several ways. Firstly, you need a different > definition of descendants than the one implied by getppid(). The parent > process ID resets to 1 when the parent exits, which would cause the > child to lose its relationship with the group. > > Secondly, I want to keep track of the group even if the top level > process terminates. For example, if apache's or postgres's master > process crashes, I want to shut down all remaining worker processes > before attempting to start a new master. > > > Why do you need to actively mark and/or track them? > > Tracking is needed for restarting services when they crash, as done by > fsc. It can also be useful for providing information to the system > administrator. > > Also, it can be useful for legacy/simple compatibility. After running > '/etc/rc.d/foo start' with a mark, the marked process(es) with ppid 1 > can be considered the processes that need to be monitored for service > foo. Admittedly, this is not fully reliable, but it is better than > matching by name on the process table (which is otherwise needed if the > daemon does not write a pid file). All good points - I actually don't really like the entire rc.d plugin stuff but wanted to be as "clean" as possible. It might be a neat project to work at removing the rc support from it. I'll be traveling to Baltimore this week for a convention, if I have some evening time I might look over this a bit. Famous last words considering I have little free time these days. :( -- Tom Rhodes From owner-freebsd-arch@FreeBSD.ORG Tue Aug 6 00:33:54 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B12F0A72; Tue, 6 Aug 2013 00:33:54 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 797D22FAC; Tue, 6 Aug 2013 00:33:53 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r760XrPF021848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 5 Aug 2013 19:33:53 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.135]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Mon, 5 Aug 2013 19:33:52 -0500 From: "Teske, Devin" To: Steve Kiernan Subject: Re: General purpose library for name/value pairs. Thread-Topic: General purpose library for name/value pairs. Thread-Index: AQHOeQDhn1IH8mH3sEeIpLvmIzmJnZlV/ouAgADVwICAAAT1AIAEYRIAgAAwqICADNgsAIAACViAgAACpwCAH4voAA== Date: Tue, 6 Aug 2013 00:33:51 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7202005DB6@ltcfiswmsgmb21> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <20130716180606.55ec081c@stevek-ubuntu> <13CA24D6AB415D428143D44749F57D7201FC9EED@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC9F3C@ltcfiswmsgmb21> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC9F3C@ltcfiswmsgmb21> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-05_07:2013-08-05,2013-08-05,1970-01-01 signatures=0 Cc: "arch@freebsd.org" , Devin Teske , Jordan Hubbard X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 00:33:54 -0000 On Jul 16, 2013, at 3:49 PM, Teske, Devin wrote: >=20 > On Jul 16, 2013, at 3:39 PM, Teske, Devin wrote: >=20 >>=20 >> On Jul 16, 2013, at 3:06 PM, Steve Kiernan wrote: >>=20 >>> On Mon, 8 Jul 2013 10:57:17 -0700 >>> Jordan Hubbard wrote: >>>=20 >>>>=20 >>>> On Jul 8, 2013, at 8:03 AM, Pawel Jakub Dawidek wrot= e: >>>>=20 >>>>> How about instead of supporting int8, uint8, int16, uint16, int32, >>>>> uint32, int64 and uint64 I'd just support 'number' type, which would = be >>>>> uint64_t. This shouldn't break transporting signed values and because= I >>>>> don't support basic types like int, long, etc. casting or conversion = has >>>>> to be done anyway. This would reduce number of supported types to: >>>>=20 >>>> That's a good idea. Since you're re-inventing Apple's XML property li= st API (but without serialization and quite a few other things), keeping th= e number of supported types down is much better than the converse - exposin= g the details of 16/32/64 bit numbers and their signedness will hang you ov= er the long term, and you can always provide explicit conversion functions = to/from Number for those who actually care. >>>>=20 >>>> String, Number, Boolean, Data, Date, Array and Dictionary are all plis= ts support, and Apple developers have gotten along pretty well for many yea= rs with that set (not supporting Dictionaries, btw, is a pretty fundamental= loss IMHO - it means you have to always iterate through lists to find your= stuff, which is meh!). >>>>=20 >>>> When Apple extended the Plist metaphor for IPC (to create XPC), they a= lso added out-of-band types like file and shared memory descriptors. You h= ave file descriptors, but not shared memory. The latter is kind of importa= nt if you want to do larger IPCs with this mechanism someday and want to su= pport "big payloads" transparently without passing the burden of the data m= anagement to the application programmer. >>>>=20 >>>> Before you also come back with "but but this is a kernel API! For jus= t one purpose!" let me just say that it's absolutely achievable to have ONE= API for talking userland<->kernel and userland<->userland with the same ty= pes and the transport mechanism(s) largely abstracted away. You don't need= two - it's already been done with one, just look next door. :) >>>>=20 >>>> If you add file serialization of this format to your picture (and add = the dictionary type) , bingo, now you have a preferences API that FreeBSD h= as lacked from day one ("just roll your own format and stick the file in /e= tc" being the canonical response to that need). >>>=20 >>> What about looking at NetBSD's libprop? >>>=20 >>> PROPLIB(3) FreeBSD Library Functions Manual PRO= PLIB(3) >>>=20 >>> NAME >>> proplib -- property container object library >>>=20 >>> LIBRARY >>> library ``libprop'' >>>=20 >>> SYNOPSIS >>> #include >>>=20 >>> DESCRIPTION >>> The proplib library provides an abstract interface for creating and >>> manipulating property lists. Property lists have object types for >>> boolean values, opaque data, numbers, and strings. Structure is pr= ovided >>> by the array and dictionary collection types. >>>=20 >>> Property lists can be passed across protection boundaries by transl= ating >>> them to an external representation. This external representation i= s an >>> XML document whose format is described by the following DTD: >>>=20 >>> http://www.apple.com/DTDs/PropertyList-1.0.dtd >>>=20 >>> Property container objects are reference counted. When an object i= s cre- >>> ated, its reference count is set to 1. Any code that keeps a refer= ence >>> to an object, including the collection types (arrays and dictionari= es), >>> must ``retain'' the object (increment its reference count). When t= hat >>> reference is dropped, the object must be ``released'' (reference co= unt >>> decremented). When an object's reference count drops to 0, it is a= uto- >>> matically freed. >>>=20 >>> The rules for managing reference counts are very simple: >>>=20 >>> o If you create an object and do not explicitly maintain a refere= nce to >>> it, you must release it. >>>=20 >>> o If you get a reference to an object from other code and wish to= main- >>> tain a reference to it, you must retain the object. You are re= spon- >>> sible for releasing the object once you drop that reference. >>>=20 >>> o You must never release an object unless you create it or retain= it. >>>=20 >>> Object collections may be iterated by creating a special iterator o= bject. >>> Iterator objects are special; they may not be retained, and they are >>> released using an iterator-specific release function. >>>=20 >>=20 >> There's also my own "figpar" free for the taking... >>=20 I don't know if I was off the mark with my suggesting figpar for the job...= but... I realized that some examples are necessary to actually bring it ho= me as a contender. I recently needed to be able to read the key/value pairs stored in ~/.dialo= grc (generated by "dialog --create-rc ~/.dialogrc"). The format of which is= simple enough... (from the head of a freshly-generated ~/.dialogrc): # Types of values: # # Number - # String - "string" # Boolean - # Attribute - (foreground,background,highlight?) Simple enough... figpar did the job wonderfully. Check it out... http://druidbsd.cvs.sf.net/viewvc/druidbsd/fdpv/dialogrc.h?revision=3D1.4&v= iew=3Dmarkup&pathrev=3Dfdpv_0_4 http://druidbsd.cvs.sf.net/viewvc/druidbsd/fdpv/dialogrc.c?revision=3D1.12&= view=3Dmarkup&pathrev=3Dfdpv_0_4 NOTE: If you looked at figpar before, have another look. I made it style(9)= compatible and enhanced it slightly. http://druidbsd.cvs.sf.net/viewvc/druidbsd/fdpv/figpar.h?revision=3D1.11&vi= ew=3Dmarkup&pathrev=3Dfdpv_0_4 http://druidbsd.cvs.sf.net/viewvc/druidbsd/fdpv/figpar.c?revision=3D1.7&vie= w=3Dmarkup&pathrev=3Dfdpv_0_4 --=20 Cheers, Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 07:58:47 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D5FC8843 for ; Wed, 7 Aug 2013 07:58:47 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2B3D7218C for ; Wed, 7 Aug 2013 07:58:46 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA20803; Wed, 07 Aug 2013 10:58:29 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1V6ydZ-000O4p-7o; Wed, 07 Aug 2013 10:58:29 +0300 Message-ID: <5201FDED.8000408@FreeBSD.org> Date: Wed, 07 Aug 2013 10:57:33 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130708 Thunderbird/17.0.7 MIME-Version: 1.0 To: Jilles Tjoelker Subject: Re: amd64: -O2 even with DEBUG References: <51F221D4.8040308@FreeBSD.org> <20130726185425.GS26412@funkthat.com> <51F37578.2080405@FreeBSD.org> <20130804202823.GB39246@stack.nl> In-Reply-To: <20130804202823.GB39246@stack.nl> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 07:58:47 -0000 on 04/08/2013 23:28 Jilles Tjoelker said the following: > On the other hand, the difference between DEBUG and !DEBUG should be > minimized to avoid heisenbugs and taking advantage of undefined > behaviour that does not work at -O2. This does make sense. But shouldn't all architectures be equal in this respect? > Also note that most standard kernel configuration files have the line > > makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols > > which suggests that it only adds debug symbols and does not lower the > optimization level (even though that is only the case on amd64). Exactly -- this is only the case on amd64, for all other architectures DEBUG implies -O. > So it seems you are asking about lowering the optimization level of > almost all amd64 kernels (there seems little reason not to generate > .symbols files). No, I am just asking for consistency. That is, if amd64 is so special among all the platforms and flavors then let this be explicitly stated somewhere. If not, then let it follow what all other architectures do. Or, conversely, all other architectures should do what amd64 does. > In my experience, debugging -O2 code is usually possible with > experience, knowledge about compiler optimizations and good compilers > and debuggers (for example, gcc and gdb were improved in this area after > the switch to GPLv3). It can be rather annoying, though, if there is a > lot of inlining or the value of the variable you need is not available > (the value may be available elsewhere in the call chain or not at all). All true. Especially kgdb-over-{email,irc} becomes annoyingly hard. -- Andriy Gapon From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 16:29:54 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CDDFC666; Wed, 7 Aug 2013 16:29:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9F18426FE; Wed, 7 Aug 2013 16:29:54 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7A801B922; Wed, 7 Aug 2013 12:29:50 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: EVFILT_PROC always returns an EV_EOF event Date: Wed, 7 Aug 2013 12:13:28 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <201307251537.04491.jhb@freebsd.org> <20130726185232.GR26412@funkthat.com> <201307261618.19408.jhb@freebsd.org> In-Reply-To: <201307261618.19408.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308071213.28577.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 07 Aug 2013 12:29:50 -0400 (EDT) Cc: arch@freebsd.org, John-Mark Gurney X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 16:29:54 -0000 On Friday, July 26, 2013 4:18:19 pm John Baldwin wrote: > On Friday, July 26, 2013 2:52:32 pm John-Mark Gurney wrote: > > John Baldwin wrote this message on Thu, Jul 25, 2013 at 15:37 -0400: > > > A co-worker ran into this undocumented behavior today. If you register an > > > EVFILT_PROC event but do not set NOTE_EXIT, you can still get an event with > > > fflags set to 0 but EV_EOF set. This is not documented in the manpage, and > > > it seems inconsistent to me. If the caller hasn't set NOTE_EXIT, then > > > presumably they do not wish to know about NOTE_EXIT events. > > > > This is probably to let the consumer know that the process no longer > > exists and that there will be no more events delivered for this process.. > > This allows the process to clean up in this case.. If you look at the > > code in filt_proc in kern_event.c, you'll also see that is forces > > _ONESHOT to be set, meaning that the knote will be deleted... > > > > It is someone documented: > > EV_EOF Filters may set this flag to indicate filter-specific EOF > > condition. > > > > But I do agree that the documentation could be better... > > > > I don't have a strong opinion on which behavior is best. I do think > > that delivering the EOF is best, since on an fd, you get _EOF when the > > socket closes, even though you didn't ask for it.. it's implicit.. > > Well, processes aren't fd's. Also, why have both NOTE_EXIT and EV_EOF for > the same thing? Also, the doc says "may" for EV_EOF, meaning it's not > guaranteed (and can not be there if there isn't a filter-specific EOF > condition). > > It seems to me that the code used EV_ONESHOT as a workaround to cleanup the > knote since it couldn't do it safely in filt_proc(), but I'm curious what > other folks think? > > I tried my test on OS X and it does not return the spurious EV_EOF event if > you don't register for NOTE_EXIT. Given this last, I'm inclined to commit my change so we are consistent with the other kqueue implementation in the wild. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 18:29:00 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 37078EEF; Wed, 7 Aug 2013 18:29:00 +0000 (UTC) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1EDD22ED4; Wed, 7 Aug 2013 18:29:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r77IT0St037416; Wed, 7 Aug 2013 18:29:00 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r77ISxDD037413; Wed, 7 Aug 2013 18:28:59 GMT (envelope-from obrien) Date: Wed, 7 Aug 2013 11:28:58 -0700 From: "David O'Brien" To: secteam@freebsd.org, freebsd-arch@freebsd.org Subject: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130807182858.GA79286@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 10.0-CURRENT X-MUA-Host: dragon.NUXI.org X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:29:00 -0000 Here is a patch that improves the ability to add RNG's to the system, even /usr/src-external as a kernel modules by creating a random(4) plugin infrastructure. thoughts? ----------%<----------%<----------%<----------%<----------%<---------- random(4) plugin infrastructure improvement. Provides ability to plugin RNGs other than yarrow in a more modular fashion. * Add random_adaptors.[ch] which is basically a store of random_adaptor's. random_adaptor is basically an adapter that plugs in to random(4). random_adaptor can only be plugged in to random(4) very early in bootup. Unplugging random_adaptor from random(4) is not supported, and is probably a bad idea anyway, due to potential loss of entropy pools. We currently have 3 random_adaptors: + yarrow + rdrand (ivy.c) + nehemeiah * Remove platform dependent logic from probe.c, and move it into corresponding registration routines of each random_adaptor provider. probe.c doesn't do anything other than picking a specific random_adaptor from a list of registered ones. * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow. random(4) device doesn't really depend on rijndael-*. Yarrow, however, does. * If the kernel doesn't have any random_adaptor adapters present then the creation of /dev/random is postponed until next random_adaptor is kldload'ed. * Fix randomdev_soft.c to refer to its own random_adaptor, instead of a system wide one. Submitted by: arthurmesh@gmail.com, obrien Obtained from: Juniper Networks Reviewed by: obrien ----------%<----------%<----------%<----------%<----------%<---------- Index: UPDATING =================================================================== --- UPDATING (revision 253845) +++ UPDATING (working copy) @@ -31,6 +31,19 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 10 disable the most expensive debugging functionality run "ln -s 'abort:false,junk:false' /etc/malloc.conf".) +201308xx: + random(4) and actual RNG implementations (aka, adaptors) have been + further decoupled. If you are running a custom kernel, you may + need to explicitly enable at least one RNG adaptor in your kernel + config. For example, to use Yarrow, add "options YARROW_RNG" to + your kernel config. For hardware backed RNGs, use either + "RDRAND_RNG" or "PADLOCK_RNG" options. + If you use random.ko via 'random_load="YES"' in /boot/loader.conf + instead of "device random", you will need to change that to + 'yarrow_rng_load="YES"', 'rdrand_rng_load="YES"', or + 'padlock_rng_load="YES"'. random.ko will be loaded automatically + as a dependency module. + 20130726: Behavior of devfs rules path matching has been changed. Pattern is now always matched against fully qualified devfs Index: share/man/man4/random.4 =================================================================== --- share/man/man4/random.4 (revision 253845) +++ share/man/man4/random.4 (working copy) @@ -23,7 +23,7 @@ .\" .\" $FreeBSD$ .\" -.Dd September 7, 2012 +.Dd August xx, 2013 .Dt RANDOM 4 .Os .Sh NAME @@ -43,6 +43,13 @@ The device will probe for certain hardware entropy sources, and use these in preference to the fallback, which is a generator implemented in software. +If the kernel environment MIB's +.Va hw.nehemiah_rng_enable +or +.Va hw.ivy_rng_enable +are set to +.Dq Li 0 , +the associated hardware entropy source will be ignored. .Pp If the device is using the software generator, @@ -74,6 +81,7 @@ device, use the command line: .Pp which results in something like: .Bd -literal -offset indent +kern.random.adaptors: yarrow kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 @@ -89,7 +97,9 @@ kern.random.yarrow.slowoverthresh: 2 (These would not be seen if a hardware generator is present.) .Pp -All settings are read/write. +Other than +.Dl kern.random.adaptors +all settings are read/write. .Pp The .Va kern.random.sys.seeded Index: sys/amd64/conf/GENERIC =================================================================== --- sys/amd64/conf/GENERIC (revision 253845) +++ sys/amd64/conf/GENERIC (working copy) @@ -295,6 +295,7 @@ device loop # Network loopback device random # Entropy device options PADLOCK_RNG # VIA Padlock RNG options RDRAND_RNG # Intel Bull Mountain RNG +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. Index: sys/arm/conf/AC100 =================================================================== --- sys/arm/conf/AC100 (revision 253845) +++ sys/arm/conf/AC100 (working copy) @@ -61,6 +61,7 @@ options MUTEX_DEBUG # Pseudo devices device random +options YARROW_RNG # Yarrow software RNG device pty device loop device md Index: sys/arm/conf/ARMADAXP =================================================================== --- sys/arm/conf/ARMADAXP (revision 253845) +++ sys/arm/conf/ARMADAXP (working copy) @@ -61,6 +61,7 @@ options KDB_TRACE # Pseudo devices device random +options YARROW_RNG # Yarrow software RNG device pty device loop device md Index: sys/arm/conf/ARNDALE =================================================================== --- sys/arm/conf/ARNDALE (revision 253845) +++ sys/arm/conf/ARNDALE (working copy) @@ -88,6 +88,7 @@ options ROOTDEVNAME=\"ufs:/dev/da0\" device loop device random +options YARROW_RNG # Yarrow software RNG device pty device md device gpio Index: sys/arm/conf/ATMEL =================================================================== --- sys/arm/conf/ATMEL (revision 253845) +++ sys/arm/conf/ATMEL (working copy) @@ -134,6 +134,7 @@ device geom_map # GEOM partition mappin # Pseudo devices. device loop # Network loopback device random # Entropy device +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. Index: sys/arm/conf/AVILA =================================================================== --- sys/arm/conf/AVILA (revision 253845) +++ sys/arm/conf/AVILA (working copy) @@ -107,6 +107,7 @@ device if_bridge device md device random # Entropy device +options YARROW_RNG # Yarrow software RNG # Wireless NIC cards device wlan # 802.11 support Index: sys/arm/conf/BEAGLEBONE =================================================================== --- sys/arm/conf/BEAGLEBONE (revision 253845) +++ sys/arm/conf/BEAGLEBONE (working copy) @@ -90,6 +90,7 @@ device pty device snp device md device random # Entropy device +options YARROW_RNG # Yarrow software RNG # I2C support device iicbus Index: sys/arm/conf/BWCT =================================================================== --- sys/arm/conf/BWCT (revision 253845) +++ sys/arm/conf/BWCT (working copy) @@ -68,6 +68,7 @@ options NO_FFS_SNAPSHOT options NO_SWAPPING device loop device random +options YARROW_RNG # Yarrow software RNG device ether device vlan device uart Index: sys/arm/conf/CAMBRIA =================================================================== --- sys/arm/conf/CAMBRIA (revision 253845) +++ sys/arm/conf/CAMBRIA (working copy) @@ -110,6 +110,7 @@ device if_bridge device md device random # Entropy device +options YARROW_RNG # Yarrow software RNG # Wireless NIC cards device wlan # 802.11 support Index: sys/arm/conf/CNS11XXNAS =================================================================== --- sys/arm/conf/CNS11XXNAS (revision 253845) +++ sys/arm/conf/CNS11XXNAS (working copy) @@ -102,6 +102,7 @@ device loop device md device random # Entropy device +options YARROW_RNG # Yarrow software RNG #options ARM_USE_SMALL_ALLOC Index: sys/arm/conf/CRB =================================================================== --- sys/arm/conf/CRB (revision 253845) +++ sys/arm/conf/CRB (working copy) @@ -105,6 +105,7 @@ options DDB #Enable the kernel debugg options XSCALE_CACHE_READ_WRITE_ALLOCATE device md device random # Entropy device +options YARROW_RNG # Yarrow software RNG device iopwdog options ARM_USE_SMALL_ALLOC Index: sys/arm/conf/CUBIEBOARD =================================================================== --- sys/arm/conf/CUBIEBOARD (revision 253845) +++ sys/arm/conf/CUBIEBOARD (working copy) @@ -92,6 +92,7 @@ device pty device snp device md device random # Entropy device +options YARROW_RNG # Yarrow software RNG # I2C support #device iicbus @@ -130,4 +131,3 @@ device miibus options FDT options FDT_DTB_STATIC makeoptions FDT_DTS_FILE=cubieboard.dts - Index: sys/arm/conf/DB-78XXX =================================================================== --- sys/arm/conf/DB-78XXX (revision 253845) +++ sys/arm/conf/DB-78XXX (working copy) @@ -55,6 +55,7 @@ device pci device loop device md device random +options YARROW_RNG # Yarrow software RNG # Serial ports device uart Index: sys/arm/conf/DB-88F5XXX =================================================================== --- sys/arm/conf/DB-88F5XXX (revision 253845) +++ sys/arm/conf/DB-88F5XXX (working copy) @@ -54,6 +54,7 @@ device pci device md device loop device random +options YARROW_RNG # Yarrow software RNG # Serial ports device uart Index: sys/arm/conf/DB-88F6XXX =================================================================== --- sys/arm/conf/DB-88F6XXX (revision 253845) +++ sys/arm/conf/DB-88F6XXX (working copy) @@ -55,6 +55,7 @@ device pci device loop device md device random +options YARROW_RNG # Yarrow software RNG # Serial ports device uart Index: sys/arm/conf/DOCKSTAR =================================================================== --- sys/arm/conf/DOCKSTAR (revision 253845) +++ sys/arm/conf/DOCKSTAR (working copy) @@ -46,6 +46,7 @@ options KDB # Pseudo devices device md device random +options YARROW_RNG # Yarrow software RNG device loop # Serial ports Index: sys/arm/conf/DREAMPLUG-1001 =================================================================== --- sys/arm/conf/DREAMPLUG-1001 (revision 253845) +++ sys/arm/conf/DREAMPLUG-1001 (working copy) @@ -62,6 +62,7 @@ device loop #Network loopback device md #Memory/malloc disk device pty #BSD-style compatibility pseudo ttys device random #Entropy device +options YARROW_RNG # Yarrow software RNG device tun #Packet tunnel. device ether #Required for all ethernet devices device vlan #802.1Q VLAN support Index: sys/arm/conf/EA3250 =================================================================== --- sys/arm/conf/EA3250 (revision 253845) +++ sys/arm/conf/EA3250 (working copy) @@ -54,6 +54,7 @@ device loop device md device pty device random +options YARROW_RNG # Yarrow software RNG # Serial ports device uart Index: sys/arm/conf/EB9200 =================================================================== --- sys/arm/conf/EB9200 (revision 253845) +++ sys/arm/conf/EB9200 (working copy) @@ -60,6 +60,7 @@ options SX_NOINLINE options NO_FFS_SNAPSHOT options NO_SWAPPING device random +options YARROW_RNG # Yarrow software RNG device loop device ether device uart Index: sys/arm/conf/EFIKA_MX =================================================================== --- sys/arm/conf/EFIKA_MX (revision 253845) +++ sys/arm/conf/EFIKA_MX (working copy) @@ -96,6 +96,7 @@ device bpf # Berkeley packet filter # Pseudo devices. device loop # Network loopback device random # Entropy device +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support #device vlan # 802.1Q VLAN support #device tun # Packet tunnel. Index: sys/arm/conf/EP80219 =================================================================== --- sys/arm/conf/EP80219 (revision 253845) +++ sys/arm/conf/EP80219 (working copy) @@ -101,6 +101,7 @@ options DDB #Enable the kernel debugg options XSCALE_CACHE_READ_WRITE_ALLOCATE device md device random # Entropy device +options YARROW_RNG # Yarrow software RNG options ARM_USE_SMALL_ALLOC # Floppy drives Index: sys/arm/conf/ETHERNUT5 =================================================================== --- sys/arm/conf/ETHERNUT5 (revision 253845) +++ sys/arm/conf/ETHERNUT5 (working copy) @@ -126,6 +126,7 @@ device geom_map # GEOM partition mappin # Pseudo devices. device loop # Network loopback device random # Entropy device +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support #device vlan # 802.1Q VLAN support #device tun # Packet tunnel. Index: sys/arm/conf/GUMSTIX =================================================================== --- sys/arm/conf/GUMSTIX (revision 253845) +++ sys/arm/conf/GUMSTIX (working copy) @@ -88,3 +88,4 @@ options DDB #Enable the kernel debugg device md device random # Entropy device +options YARROW_RNG # Yarrow software RNG Index: sys/arm/conf/HL200 =================================================================== --- sys/arm/conf/HL200 (revision 253845) +++ sys/arm/conf/HL200 (working copy) @@ -65,6 +65,7 @@ options RWLOCK_NOINLINE options NO_FFS_SNAPSHOT options NO_SWAPPING device random +options YARROW_RNG # Yarrow software RNG device loop device ether device uart Index: sys/arm/conf/HL201 =================================================================== --- sys/arm/conf/HL201 (revision 253845) +++ sys/arm/conf/HL201 (working copy) @@ -67,6 +67,7 @@ options RWLOCK_NOINLINE options NO_FFS_SNAPSHOT options NO_SWAPPING device random +options YARROW_RNG # Yarrow software RNG device loop device ether device uart @@ -129,4 +130,3 @@ device pass # Passthrough device (dire #device wlan_tkip # 802.11 TKIP support #device wlan_amrr # AMRR transmit rate control algorithm options ROOTDEVNAME=\"ufs:da0s1a\" - Index: sys/arm/conf/IQ31244 =================================================================== --- sys/arm/conf/IQ31244 (revision 253845) +++ sys/arm/conf/IQ31244 (working copy) @@ -106,6 +106,7 @@ options DDB #Enable the kernel debugg options XSCALE_CACHE_READ_WRITE_ALLOCATE device md device random # Entropy device +options YARROW_RNG # Yarrow software RNG options ARM_USE_SMALL_ALLOC # Floppy drives Index: sys/arm/conf/KB920X =================================================================== --- sys/arm/conf/KB920X (revision 253845) +++ sys/arm/conf/KB920X (working copy) @@ -66,6 +66,7 @@ options SX_NOINLINE options NO_FFS_SNAPSHOT options NO_SWAPPING device random +options YARROW_RNG # Yarrow software RNG device loop device ether device uart Index: sys/arm/conf/LN2410SBC =================================================================== --- sys/arm/conf/LN2410SBC (revision 253845) +++ sys/arm/conf/LN2410SBC (working copy) @@ -62,6 +62,7 @@ options SX_NOINLINE options NO_FFS_SNAPSHOT options NO_SWAPPING device random +options YARROW_RNG # Yarrow software RNG device loop device ether @@ -83,4 +84,3 @@ device ohci device umass device scbus # SCSI bus (required for da) device da # Direct Access (disks) - Index: sys/arm/conf/NSLU =================================================================== --- sys/arm/conf/NSLU (revision 253845) +++ sys/arm/conf/NSLU (working copy) @@ -105,6 +105,7 @@ device loop device md device random # Entropy device +options YARROW_RNG # Yarrow software RNG #options ARM_USE_SMALL_ALLOC Index: sys/arm/conf/PANDABOARD =================================================================== --- sys/arm/conf/PANDABOARD (revision 253845) +++ sys/arm/conf/PANDABOARD (working copy) @@ -110,6 +110,7 @@ device md #options MD_ROOT_SIZE=7560 device random # Entropy device +options YARROW_RNG # Yarrow software RNG # USB support device usb Index: sys/arm/conf/QILA9G20 =================================================================== --- sys/arm/conf/QILA9G20 (revision 253845) +++ sys/arm/conf/QILA9G20 (working copy) @@ -77,6 +77,7 @@ options NO_SWAPPING #options DIAGNOSTIC device random +options YARROW_RNG # Yarrow software RNG device loop device bpf device ether Index: sys/arm/conf/RPI-B =================================================================== --- sys/arm/conf/RPI-B (revision 253845) +++ sys/arm/conf/RPI-B (working copy) @@ -86,6 +86,7 @@ options INVARIANT_SUPPORT #Extra sanity device md device random # Entropy device +options YARROW_RNG # Yarrow software RNG # USB support device usb Index: sys/arm/conf/SAM9260EK =================================================================== --- sys/arm/conf/SAM9260EK (revision 253845) +++ sys/arm/conf/SAM9260EK (working copy) @@ -134,6 +134,7 @@ device mmcsd # MMC/SD memory card # Pseudo devices. device loop # Network loopback device random # Entropy device +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support #device vlan # 802.1Q VLAN support #device tun # Packet tunnel. Index: sys/arm/conf/SAM9G20EK =================================================================== --- sys/arm/conf/SAM9G20EK (revision 253845) +++ sys/arm/conf/SAM9G20EK (working copy) @@ -76,6 +76,7 @@ options NO_SWAPPING #options DIAGNOSTIC device random +options YARROW_RNG # Yarrow software RNG device loop device bpf device ether Index: sys/arm/conf/SAM9X25EK =================================================================== --- sys/arm/conf/SAM9X25EK (revision 253845) +++ sys/arm/conf/SAM9X25EK (working copy) @@ -77,6 +77,7 @@ options NO_SWAPPING #options DIAGNOSTIC device random +options YARROW_RNG # Yarrow software RNG device pty device loop device bpf @@ -150,4 +151,3 @@ device miibus #device wlan_ccmp # 802.11 CCMP support #device wlan_tkip # 802.11 TKIP support #device wlan_amrr # AMRR transmit rate control algorithm - Index: sys/arm/conf/SHEEVAPLUG =================================================================== --- sys/arm/conf/SHEEVAPLUG (revision 253845) +++ sys/arm/conf/SHEEVAPLUG (working copy) @@ -45,6 +45,7 @@ options KDB # Pseudo devices device random +options YARROW_RNG # Yarrow software RNG device loop # Serial ports Index: sys/arm/conf/SN9G45 =================================================================== --- sys/arm/conf/SN9G45 (revision 253845) +++ sys/arm/conf/SN9G45 (working copy) @@ -76,6 +76,7 @@ options NO_SWAPPING #options DIAGNOSTIC device random +options YARROW_RNG # Yarrow software RNG device loop device bpf device ether Index: sys/arm/conf/TS7800 =================================================================== --- sys/arm/conf/TS7800 (revision 253845) +++ sys/arm/conf/TS7800 (working copy) @@ -48,6 +48,7 @@ device pci device md device loop device random +options YARROW_RNG # Yarrow software RNG # Serial ports device uart Index: sys/arm/conf/VERSATILEPB =================================================================== --- sys/arm/conf/VERSATILEPB (revision 253845) +++ sys/arm/conf/VERSATILEPB (working copy) @@ -94,6 +94,7 @@ options INVARIANT_SUPPORT #Extra sanity device md device random # Entropy device +options YARROW_RNG # Yarrow software RNG # Flattened Device Tree options FDT Index: sys/arm/conf/ZEDBOARD =================================================================== --- sys/arm/conf/ZEDBOARD (revision 253845) +++ sys/arm/conf/ZEDBOARD (working copy) @@ -66,6 +66,7 @@ options KDB device loop device random +options YARROW_RNG # Yarrow software RNG device ether device if_cgem # Zynq-7000 gig ethernet device device mii Index: sys/conf/NOTES =================================================================== --- sys/conf/NOTES (revision 253845) +++ sys/conf/NOTES (working copy) @@ -1132,6 +1132,9 @@ options VFS_AIO # Cryptographically secure random number generator; /dev/random device random +# Yarrow software RNG adapter for random +options YARROW_RNG + # The system memory devices; /dev/mem, /dev/kmem device mem Index: sys/conf/files =================================================================== --- sys/conf/files (revision 253845) +++ sys/conf/files (working copy) @@ -540,8 +540,8 @@ crypto/des/des_ecb.c optional crypto | crypto/des/des_setkey.c optional crypto | ipsec | netsmb crypto/rc4/rc4.c optional netgraph_mppc_encryption | kgssapi crypto/rijndael/rijndael-alg-fst.c optional crypto | geom_bde | \ - ipsec | random | wlan_ccmp -crypto/rijndael/rijndael-api-fst.c optional geom_bde | random + ipsec | yarrow_rng | wlan_ccmp +crypto/rijndael/rijndael-api-fst.c optional geom_bde | yarrow_rng crypto/rijndael/rijndael-api.c optional crypto | ipsec | wlan_ccmp crypto/sha1.c optional carp | crypto | ipsec | \ netgraph_mppc_encryption | sctp @@ -2030,11 +2030,12 @@ rt2860.fw optional rt2860fw | ralfw \ no-obj no-implicit-rule \ clean "rt2860.fw" dev/random/harvest.c standard -dev/random/hash.c optional random +dev/random/hash.c optional yarrow_rng dev/random/probe.c optional random +dev/random/random_adaptors.c standard dev/random/randomdev.c optional random -dev/random/randomdev_soft.c optional random -dev/random/yarrow.c optional random +dev/random/randomdev_soft.c optional yarrow_rng +dev/random/yarrow.c optional yarrow_rng dev/rc/rc.c optional rc dev/re/if_re.c optional re dev/rndtest/rndtest.c optional rndtest Index: sys/conf/options =================================================================== --- sys/conf/options (revision 253845) +++ sys/conf/options (working copy) @@ -905,3 +905,6 @@ RACCT opt_global.h # Resource Limits RCTL opt_global.h + +# Software random number generators for random(4) +YARROW_RNG opt_dontuse.h Index: sys/dev/random/ivy.c =================================================================== --- sys/dev/random/ivy.c (revision 253846) +++ sys/dev/random/ivy.c (working copy) @@ -28,16 +28,19 @@ #include __FBSDID("$FreeBSD$"); -#include "opt_cpu.h" - -#ifdef RDRAND_RNG - #include #include +#include #include +#include #include #include #include + +#include +#include + +#include #include #define RETRY_COUNT 10 @@ -46,7 +49,7 @@ static void random_ivy_init(void); static void random_ivy_deinit(void); static int random_ivy_read(void *, int); -struct random_systat random_ivy = { +struct random_adaptor random_ivy = { .ident = "Hardware, Intel IvyBridge+ RNG", .init = random_ivy_init, .deinit = random_ivy_deinit, @@ -114,4 +117,32 @@ random_ivy_read(void *buf, int c) return (c - count); } +static int +rdrand_modevent(module_t mod, int type, void *unused) +{ + + switch (type) { + case MOD_LOAD: + if (cpu_feature2 & CPUID2_RDRAND) { + random_adaptor_register("rdrand", &random_ivy); + EVENTHANDLER_INVOKE(random_adaptor_attach, &random_ivy); + return (0); + } else { +#ifndef KLD_MODULE + if (bootverbose) +#endif + printf( + "%s: RDRAND feature is not present on this CPU\n", + random_ivy.ident); +#ifdef KLD_MODULE + return (ENXIO); +#else + return (0); #endif + } + } + + return (EINVAL); +} + +RANDOM_ADAPTOR_MODULE(random_rdrand, rdrand_modevent, 1); Index: sys/dev/random/nehemiah.c =================================================================== --- sys/dev/random/nehemiah.c (revision 253846) +++ sys/dev/random/nehemiah.c (working copy) @@ -28,19 +28,20 @@ #include __FBSDID("$FreeBSD$"); -#include "opt_cpu.h" - -#ifdef PADLOCK_RNG - #include #include #include #include +#include #include #include +#include #include +#include +#include +#include #include #define RANDOM_BLOCK_SIZE 256 @@ -50,7 +51,7 @@ static void random_nehemiah_init(void); static void random_nehemiah_deinit(void); static int random_nehemiah_read(void *, int); -struct random_systat random_nehemiah = { +struct random_adaptor random_nehemiah = { .ident = "Hardware, VIA Nehemiah", .init = random_nehemiah_init, .deinit = random_nehemiah_deinit, @@ -208,4 +209,33 @@ random_nehemiah_read(void *buf, int c) return (c); } +static int +nehemiah_modevent(module_t mod, int type, void *unused) +{ + + switch (type) { + case MOD_LOAD: + if (via_feature_rng & VIA_HAS_RNG) { + random_adaptor_register("nehemiah", &random_nehemiah); + EVENTHANDLER_INVOKE(random_adaptor_attach, + &random_nehemiah); + return (0); + } else { +#ifndef KLD_MODULE + if (bootverbose) +#endif + printf( + "%s: VIA RNG feature is not present on this CPU\n", + random_nehemiah.ident); +#ifdef KLD_MODULE + return (ENXIO); +#else + return (0); #endif + } + } + + return (EINVAL); +} + +RANDOM_ADAPTOR_MODULE(nehemiah, nehemiah_modevent, 1); Index: sys/dev/random/probe.c =================================================================== --- sys/dev/random/probe.c (revision 253846) +++ sys/dev/random/probe.c (working copy) @@ -28,66 +28,35 @@ #include __FBSDID("$FreeBSD$"); -#if defined(__amd64__) || (defined(__i386__) && !defined(PC98)) +#if defined(__amd64__) || defined(__i386__) #include "opt_cpu.h" #endif -#include #include #include #include -#include -#include #include -#include - -#if defined(__amd64__) || (defined(__i386__) && !defined(PC98)) -#include -#include -#include -#include -#endif +#include #include -#include - -#if defined(__amd64__) || (defined(__i386__) && !defined(PC98)) -#ifdef PADLOCK_RNG -extern struct random_systat random_nehemiah; -#endif -#ifdef RDRAND_RNG -extern struct random_systat random_ivy; -#endif -#endif void -random_ident_hardware(struct random_systat **systat) +random_ident_hardware(struct random_adaptor **adaptor) { + struct random_adaptor *tmp; + int enable; - /* Set default to software */ - *systat = &random_yarrow; + /* Set default to software (yarrow) */ + *adaptor = random_adaptor_get("yarrow"); /* Then go looking for hardware */ -#if defined(__amd64__) || (defined(__i386__) && !defined(PC98)) -#ifdef PADLOCK_RNG - if (via_feature_rng & VIA_HAS_RNG) { - int enable; - - enable = 1; - TUNABLE_INT_FETCH("hw.nehemiah_rng_enable", &enable); - if (enable) - *systat = &random_nehemiah; - } -#endif -#ifdef RDRAND_RNG - if (cpu_feature2 & CPUID2_RDRAND) { - int enable; + enable = 1; + TUNABLE_INT_FETCH("hw.nehemiah_rng_enable", &enable); + if (enable && (tmp = random_adaptor_get("nehemiah"))) + *adaptor = tmp; - enable = 1; - TUNABLE_INT_FETCH("hw.ivy_rng_enable", &enable); - if (enable) - *systat = &random_ivy; - } -#endif -#endif + enable = 1; + TUNABLE_INT_FETCH("hw.ivy_rng_enable", &enable); + if (enable && (tmp = random_adaptor_get("rdrand"))) + *adaptor = tmp; } Index: sys/dev/random/random_adaptors.c =================================================================== --- sys/dev/random/random_adaptors.c (revision 0) +++ sys/dev/random/random_adaptors.c (working copy) @@ -0,0 +1,137 @@ +/*- + * Copyright (c) 2013 Arthur Mesh + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer + * in this position and unchanged. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +LIST_HEAD(adaptors_head, random_adaptors); +static struct adaptors_head adaptors = LIST_HEAD_INITIALIZER(adaptors); +static struct sx adaptors_lock; /* need a sleepable lock */ + +/* List for the dynamic sysctls */ +static struct sysctl_ctx_list random_clist; + +MALLOC_DEFINE(M_RANDOM_ADAPTORS, "random_adaptors", "Random adaptors buffers"); + +int +random_adaptor_register(const char *name, struct random_adaptor *rsp) +{ + struct random_adaptors *rpp; + + KASSERT(name != NULL && rsp != NULL, ("invalid input to %s", __func__)); + + rpp = malloc(sizeof(struct random_adaptors), M_RANDOM_ADAPTORS, M_WAITOK); + rpp->name = name; + rpp->rsp = rsp; + + sx_xlock(&adaptors_lock); + LIST_INSERT_HEAD(&adaptors, rpp, entries); + sx_xunlock(&adaptors_lock); + + return (0); +} + +struct random_adaptor * +random_adaptor_get(const char *name) +{ + struct random_adaptors *rpp; + struct random_adaptor *rsp; + + rsp = NULL; + + sx_slock(&adaptors_lock); + + LIST_FOREACH(rpp, &adaptors, entries) + if (strcmp(rpp->name, name) == 0) + rsp = rpp->rsp; + + sx_sunlock(&adaptors_lock); + + return (rsp); +} + +static void +random_adaptors_deinit(void *unused) +{ + + sx_destroy(&adaptors_lock); + sysctl_ctx_free(&random_clist); +} + +static int +random_sysctl_adaptors_handler(SYSCTL_HANDLER_ARGS) +{ + struct random_adaptors *rpp; + int error; + + error = 0; + + sx_slock(&adaptors_lock); + + if (LIST_EMPTY(&adaptors)) + error = SYSCTL_OUT(req, "", strlen("")); + + LIST_FOREACH(rpp, &adaptors, entries) { + if (0 != SYSCTL_OUT(req, rpp->name, strlen(rpp->name))) + break; + } + + sx_sunlock(&adaptors_lock); + + return (error); +} + +static void +random_adaptors_init(void *unused) +{ + + SYSCTL_PROC(_kern_random, OID_AUTO, adaptors, + CTLTYPE_STRING | CTLFLAG_RD | CTLFLAG_MPSAFE, + NULL, 0, random_sysctl_adaptors_handler, "", + "Random Number Generator adaptors"); + + sx_init(&adaptors_lock, "random_adaptors"); +} + +SYSCTL_NODE(_kern, OID_AUTO, random, CTLFLAG_RW, 0, "Random Number Generator"); + +SYSINIT(random_adaptors, SI_SUB_DRIVERS, SI_ORDER_FIRST, random_adaptors_init, + NULL); +SYSUNINIT(random_adaptors, SI_SUB_DRIVERS, SI_ORDER_FIRST, + random_adaptors_deinit, NULL); Property changes on: sys/dev/random/random_adaptors.c ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Index: sys/dev/random/random_adaptors.h =================================================================== --- sys/dev/random/random_adaptors.h (revision 0) +++ sys/dev/random/random_adaptors.h (working copy) @@ -0,0 +1,66 @@ +/*- + * Copyright (c) 2013 Arthur Mesh + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer + * in this position and unchanged. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef __RANDOM_ADAPTORS_H__ +#define __RANDOM_ADAPTORS_H__ + +#include + +struct random_adaptors { + LIST_ENTRY(random_adaptors) entries; /* list of providesr */ + const char *name; /* name of random adaptor */ + struct random_adaptor *rsp; +}; + +struct random_adaptor *random_adaptor_get(const char *); +int random_adaptor_register(const char *, struct random_adaptor *); + +/* + * random_adaptor's should be registered prior to + * random module (SI_SUB_DRIVERS/SI_ORDER_MIDDLE) + */ +#define RANDOM_ADAPTOR_MODULE(name, modevent, ver) \ + static moduledata_t name##_mod = { \ + #name, \ + modevent, \ + 0 \ + }; \ + DECLARE_MODULE(name, name##_mod, SI_SUB_DRIVERS, \ + SI_ORDER_SECOND); \ + MODULE_VERSION(name, ver); \ + MODULE_DEPEND(name, random, 1, 1, 1); + +typedef void (*random_adaptor_attach_hook)(void *, struct random_adaptor *); +EVENTHANDLER_DECLARE(random_adaptor_attach, random_adaptor_attach_hook); + +/* kern.random sysctls */ +#ifdef SYSCTL_DECL /* from sysctl.h */ +SYSCTL_DECL(_kern_random); +#endif /* SYSCTL_DECL */ + +#endif /* __RANDOM_ADAPTORS_H__ */ Property changes on: sys/dev/random/random_adaptors.h ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: sys/dev/random/randomdev.c =================================================================== --- sys/dev/random/randomdev.c (revision 253846) +++ sys/dev/random/randomdev.c (working copy) @@ -70,12 +70,15 @@ static struct cdevsw random_cdevsw = { .d_name = "random", }; -struct random_systat *random_systat; +static struct random_adaptor *random_adaptor; +static eventhandler_tag attach_tag; +static int random_inited; + /* For use with make_dev(9)/destroy_dev(9). */ static struct cdev *random_dev; -/* Used to fake out unused random calls in random_systat */ +/* Used to fake out unused random calls in random_adaptor */ void random_null_func(void) { @@ -88,8 +91,8 @@ random_close(struct cdev *dev __unused, { if ((flags & FWRITE) && (priv_check(td, PRIV_RANDOM_RESEED) == 0) && (securelevel_gt(td->td_ucred, 0) == 0)) { - (*random_systat->reseed)(); - random_systat->seeded = 1; + (*random_adaptor->reseed)(); + random_adaptor->seeded = 1; arc4rand(NULL, 0, 1); /* Reseed arc4random as well. */ } @@ -104,8 +107,8 @@ random_read(struct cdev *dev __unused, s void *random_buf; /* Blocking logic */ - if (!random_systat->seeded) - error = (*random_systat->block)(flag); + if (!random_adaptor->seeded) + error = (*random_adaptor->block)(flag); /* The actual read */ if (!error) { @@ -114,7 +117,7 @@ random_read(struct cdev *dev __unused, s while (uio->uio_resid > 0 && !error) { c = MIN(uio->uio_resid, PAGE_SIZE); - c = (*random_systat->read)(random_buf, c); + c = (*random_adaptor->read)(random_buf, c); error = uiomove(random_buf, c, uio); } @@ -139,7 +142,7 @@ random_write(struct cdev *dev __unused, error = uiomove(random_buf, c, uio); if (error) break; - (*random_systat->write)(random_buf, c); + (*random_adaptor->write)(random_buf, c); } free(random_buf, M_TEMP); @@ -172,14 +175,37 @@ random_poll(struct cdev *dev __unused, i int revents = 0; if (events & (POLLIN | POLLRDNORM)) { - if (random_systat->seeded) + if (random_adaptor->seeded) revents = events & (POLLIN | POLLRDNORM); else - revents = (*random_systat->poll) (events,td); + revents = (*random_adaptor->poll) (events,td); } return (revents); } +static void +random_initialize(void *p, struct random_adaptor *s) +{ + if (random_inited) { + printf("random: <%s> already initialized\n", + random_adaptor->ident); + return; + } + + random_adaptor = s; + + (s->init)(); + + printf("random: <%s> initialized\n", s->ident); + + random_dev = make_dev_credf(MAKEDEV_ETERNAL_KLD, &random_cdevsw, + RANDOM_MINOR, NULL, UID_ROOT, GID_WHEEL, 0666, "random"); + make_dev_alias(random_dev, "urandom"); /* XXX Deprecated */ + + /* mark random(4) as initialized, to avoid being called again */ + random_inited = 1; +} + /* ARGSUSED */ static int random_modevent(module_t mod __unused, int type, void *data __unused) @@ -188,23 +214,29 @@ random_modevent(module_t mod __unused, i switch (type) { case MOD_LOAD: - random_ident_hardware(&random_systat); - (*random_systat->init)(); - - if (bootverbose) - printf("random: \n", - random_systat->ident); + random_ident_hardware(&random_adaptor); - random_dev = make_dev_credf(MAKEDEV_ETERNAL_KLD, &random_cdevsw, - RANDOM_MINOR, NULL, UID_ROOT, GID_WHEEL, 0666, "random"); - make_dev_alias(random_dev, "urandom"); /* XXX Deprecated */ + if (random_adaptor == NULL) { + printf( + "random: No random adaptor attached, postponing initialization\n"); + attach_tag = EVENTHANDLER_REGISTER(random_adaptor_attach, + random_initialize, NULL, EVENTHANDLER_PRI_ANY); + } else { + random_initialize(NULL, random_adaptor); + } break; case MOD_UNLOAD: - (*random_systat->deinit)(); - - destroy_dev(random_dev); + if (random_adaptor != NULL) { + (*random_adaptor->deinit)(); + destroy_dev(random_dev); + } + /* Unregister the event handler */ + if (attach_tag != NULL) { + EVENTHANDLER_DEREGISTER(random_adaptor_attach, + attach_tag); + } break; Index: sys/dev/random/randomdev.h =================================================================== --- sys/dev/random/randomdev.h (revision 253846) +++ sys/dev/random/randomdev.h (working copy) @@ -38,7 +38,7 @@ typedef void random_write_func_t(void *, typedef int random_poll_func_t(int, struct thread *); typedef void random_reseed_func_t(void); -struct random_systat { +struct random_adaptor { struct selinfo rsel; const char *ident; int seeded; @@ -51,7 +51,5 @@ struct random_systat { random_reseed_func_t *reseed; }; -extern struct random_systat *random_systat; - -extern void random_ident_hardware(struct random_systat **); +extern void random_ident_hardware(struct random_adaptor **); extern void random_null_func(void); Index: sys/dev/random/randomdev_soft.c =================================================================== --- sys/dev/random/randomdev_soft.c (revision 253846) +++ sys/dev/random/randomdev_soft.c (working copy) @@ -38,6 +38,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -50,6 +51,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include @@ -63,7 +65,7 @@ static int random_yarrow_poll(int event, static int random_yarrow_block(int flag); static void random_yarrow_flush_reseed(void); -struct random_systat random_yarrow = { +struct random_adaptor random_yarrow = { .ident = "Software, Yarrow", .init = random_yarrow_init, .deinit = random_yarrow_deinit, @@ -103,7 +105,7 @@ static int random_kthread_control = 0; static struct proc *random_kthread_proc; /* List for the dynamic sysctls */ -struct sysctl_ctx_list random_clist; +static struct sysctl_ctx_list random_clist; /* ARGSUSED */ static int @@ -120,25 +122,20 @@ random_yarrow_init(void) { int error, i; struct harvest *np; - struct sysctl_oid *random_o, *random_sys_o, *random_sys_harvest_o; + struct sysctl_oid *random_sys_o, *random_sys_harvest_o; enum esource e; - random_o = SYSCTL_ADD_NODE(&random_clist, - SYSCTL_STATIC_CHILDREN(_kern), - OID_AUTO, "random", CTLFLAG_RW, 0, - "Software Random Number Generator"); - - random_yarrow_init_alg(&random_clist, random_o); + random_yarrow_init_alg(&random_clist); random_sys_o = SYSCTL_ADD_NODE(&random_clist, - SYSCTL_CHILDREN(random_o), + SYSCTL_STATIC_CHILDREN(_kern_random), OID_AUTO, "sys", CTLFLAG_RW, 0, "Entropy Device Parameters"); SYSCTL_ADD_PROC(&random_clist, SYSCTL_CHILDREN(random_sys_o), OID_AUTO, "seeded", CTLTYPE_INT | CTLFLAG_RW, - &random_systat->seeded, 1, random_check_boolean, "I", + &random_yarrow.seeded, 1, random_check_boolean, "I", "Seeded State"); random_sys_harvest_o = SYSCTL_ADD_NODE(&random_clist, @@ -362,10 +359,10 @@ random_yarrow_write(void *buf, int count void random_yarrow_unblock(void) { - if (!random_systat->seeded) { - random_systat->seeded = 1; - selwakeuppri(&random_systat->rsel, PUSER); - wakeup(random_systat); + if (!random_yarrow.seeded) { + random_yarrow.seeded = 1; + selwakeuppri(&random_yarrow.rsel, PUSER); + wakeup(&random_yarrow); } (void)atomic_cmpset_int(&arc4rand_iniseed_state, ARC4_ENTR_NONE, ARC4_ENTR_HAVE); @@ -377,10 +374,10 @@ random_yarrow_poll(int events, struct th int revents = 0; mtx_lock(&random_reseed_mtx); - if (random_systat->seeded) + if (random_yarrow.seeded) revents = events & (POLLIN | POLLRDNORM); else - selrecord(td, &random_systat->rsel); + selrecord(td, &random_yarrow.rsel); mtx_unlock(&random_reseed_mtx); return revents; @@ -394,12 +391,12 @@ random_yarrow_block(int flag) mtx_lock(&random_reseed_mtx); /* Blocking logic */ - while (!random_systat->seeded && !error) { + while (!random_yarrow.seeded && !error) { if (flag & O_NONBLOCK) error = EWOULDBLOCK; else { printf("Entropy device is blocking.\n"); - error = msleep(random_systat, + error = msleep(&random_yarrow, &random_reseed_mtx, PUSER | PCATCH, "block", 0); } @@ -420,3 +417,30 @@ random_yarrow_flush_reseed(void) random_yarrow_reseed(); } + +static int +yarrow_modevent(module_t mod, int type, void *unused) +{ + + switch (type) { + case MOD_LOAD: + random_adaptor_register("yarrow", &random_yarrow); + /* + * For statically built kernels that contain both random.ko and + * *_rng.ko, this event handler will do nothing, since + * random.ko is loaded after *_rng.ko's, and hence hasn't yet + * registered for this event. + * + * In case where both random.ko and *_rng.ko are built as + * modules, random.ko is loaded prior to *_rng.ko's (by + * dependency). This event handler is there to delay creation + * of /dev/{u,}random and attachment of this *_rng.ko. + */ + EVENTHANDLER_INVOKE(random_adaptor_attach, &random_yarrow); + return (0); + } + + return (EINVAL); +} + +RANDOM_ADAPTOR_MODULE(yarrow, yarrow_modevent, 1); Index: sys/dev/random/randomdev_soft.h =================================================================== --- sys/dev/random/randomdev_soft.h (revision 253846) +++ sys/dev/random/randomdev_soft.h (working copy) @@ -72,10 +72,10 @@ void random_process_event(struct harvest void random_yarrow_reseed(void); void random_yarrow_unblock(void); -void random_yarrow_init_alg(struct sysctl_ctx_list *, struct sysctl_oid *); +void random_yarrow_init_alg(struct sysctl_ctx_list *); void random_yarrow_deinit_alg(void); -extern struct random_systat random_yarrow; +extern struct random_adaptor random_yarrow; extern struct mtx random_reseed_mtx; /* If this was c++, this would be a template */ Index: sys/dev/random/yarrow.c =================================================================== --- sys/dev/random/yarrow.c (revision 253846) +++ sys/dev/random/yarrow.c (working copy) @@ -41,6 +41,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include @@ -101,7 +102,7 @@ random_process_event(struct harvest *eve } void -random_yarrow_init_alg(struct sysctl_ctx_list *clist, struct sysctl_oid *in_o) +random_yarrow_init_alg(struct sysctl_ctx_list *clist) { int i; struct sysctl_oid *random_yarrow_o; @@ -110,7 +111,7 @@ random_yarrow_init_alg(struct sysctl_ctx * have a very good clue about what they do! */ random_yarrow_o = SYSCTL_ADD_NODE(clist, - SYSCTL_CHILDREN(in_o), + SYSCTL_STATIC_CHILDREN(_kern_random), OID_AUTO, "yarrow", CTLFLAG_RW, 0, "Yarrow Parameters"); Index: sys/i386/conf/GENERIC =================================================================== --- sys/i386/conf/GENERIC (revision 253845) +++ sys/i386/conf/GENERIC (working copy) @@ -309,6 +309,7 @@ device loop # Network loopback device random # Entropy device options PADLOCK_RNG # VIA Padlock RNG options RDRAND_RNG # Intel Bull Mountain RNG +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. Index: sys/i386/conf/XBOX =================================================================== --- sys/i386/conf/XBOX (revision 253845) +++ sys/i386/conf/XBOX (working copy) @@ -62,6 +62,7 @@ device pass # Passthrough device (dire # Pseudo devices. device loop # Network loopback device random # Entropy device +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support #device tun # Packet tunnel. #device md # Memory "disks" Index: sys/i386/conf/XEN =================================================================== --- sys/i386/conf/XEN (revision 253845) +++ sys/i386/conf/XEN (working copy) @@ -76,6 +76,7 @@ device pci # Pseudo devices. device loop # Network loopback device random # Entropy device +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support device tun # Packet tunnel. device md # Memory "disks" @@ -90,4 +91,3 @@ options AH_SUPPORT_AR5416 # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter - Index: sys/ia64/conf/GENERIC =================================================================== --- sys/ia64/conf/GENERIC (revision 253845) +++ sys/ia64/conf/GENERIC (working copy) @@ -198,6 +198,7 @@ device loop # Network loopback device md # Memory "disks" device puc # Multi I/O cards and multi-channel UARTs device random # Entropy device +options YARROW_RNG # Yarrow software RNG device tun # Packet tunnel. device uart # Serial port (UART) device vlan # 802.1Q VLAN support Index: sys/mips/conf/AR71XX_BASE =================================================================== --- sys/mips/conf/AR71XX_BASE (revision 253845) +++ sys/mips/conf/AR71XX_BASE (working copy) @@ -24,7 +24,7 @@ makeoptions DEBUG=-g #Build kernel with # Build these as modules so small platform builds will have the # modules already built. -makeoptions MODULES_OVERRIDE="random gpio ar71xx if_gif if_gre if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_rssadapt wlan_amrr ath ath_pci" +makeoptions MODULES_OVERRIDE="random yarrow_rng gpio ar71xx if_gif if_gre if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_rssadapt wlan_amrr ath ath_pci" options DDB options KDB @@ -115,6 +115,7 @@ device ether device md device bpf device random +options YARROW_RNG # Yarrow software RNG device if_bridge device gif # ip[46] in ip[46] tunneling protocol device gre # generic encapsulation - only for IPv4 in IPv4 though atm Index: sys/mips/conf/AR724X_BASE =================================================================== --- sys/mips/conf/AR724X_BASE (revision 253845) +++ sys/mips/conf/AR724X_BASE (working copy) @@ -25,7 +25,7 @@ makeoptions DEBUG=-g #Build kernel with # Build these as modules so small platform builds will have the # modules already built. -makeoptions MODULES_OVERRIDE="random gpio ar71xx if_gif if_gre if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_rssadapt wlan_amrr ath ath_pci hwpmc cam" +makeoptions MODULES_OVERRIDE="random yarrow_rng gpio ar71xx if_gif if_gre if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_rssadapt wlan_amrr ath ath_pci hwpmc cam" options DDB options KDB Index: sys/mips/conf/AR91XX_BASE =================================================================== --- sys/mips/conf/AR91XX_BASE (revision 253845) +++ sys/mips/conf/AR91XX_BASE (working copy) @@ -20,7 +20,7 @@ files "../atheros/files.ar71xx" hints "AR91XX_BASE.hints" makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols -makeoptions MODULES_OVERRIDE="random gpio ar71xx if_gif if_gre if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_rssadapt wlan_amrr ath ath_ahb hwpmc" +makeoptions MODULES_OVERRIDE="random yarrow_rng gpio ar71xx if_gif if_gre if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_rssadapt wlan_amrr ath ath_ahb hwpmc" options DDB options KDB @@ -113,6 +113,7 @@ device ether device md device bpf device random +options YARROW_RNG # Yarrow software RNG device if_bridge device gpio device gpioled Index: sys/mips/conf/AR933X_BASE =================================================================== --- sys/mips/conf/AR933X_BASE (revision 253845) +++ sys/mips/conf/AR933X_BASE (working copy) @@ -20,7 +20,7 @@ files "../atheros/files.ar71xx" hints "AR933X_BASE.hints" makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols -# makeoptions MODULES_OVERRIDE="random gpio ar71xx if_gif if_gre if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_rssadapt wlan_amrr ath ath_ahb hwpmc" +# makeoptions MODULES_OVERRIDE="random yarrow_rng gpio ar71xx if_gif if_gre if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip wlan_ccmp wlan_rssadapt wlan_amrr ath ath_ahb hwpmc" makeoptions MODULES_OVERRIDE="" options DDB @@ -119,6 +119,7 @@ device ether device md device bpf device random +options YARROW_RNG # Yarrow software RNG device if_bridge device gpio device gpioled Index: sys/mips/conf/BERI_TEMPLATE =================================================================== --- sys/mips/conf/BERI_TEMPLATE (revision 253845) +++ sys/mips/conf/BERI_TEMPLATE (working copy) @@ -55,4 +55,5 @@ device md device ether device loop device random +options YARROW_RNG # Yarrow software RNG device snp Index: sys/mips/conf/DIR-825 =================================================================== --- sys/mips/conf/DIR-825 (revision 253845) +++ sys/mips/conf/DIR-825 (working copy) @@ -20,6 +20,7 @@ hints "DIR-825.hints" # Since the kernel image must fit inside 1024KiB, we have to build almost # everything as modules. nodevice random +nooptions YARROW_RNG nodevice gpio nodevice gpioled nodevice gif Index: sys/mips/conf/GXEMUL =================================================================== --- sys/mips/conf/GXEMUL (revision 253845) +++ sys/mips/conf/GXEMUL (working copy) @@ -51,6 +51,7 @@ device gxemul_ether # Pseudo devices. device loop # Network loopback device random # Entropy device +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support device tun # Packet tunnel. device md # Memory "disks" Index: sys/mips/conf/OCTEON1 =================================================================== --- sys/mips/conf/OCTEON1 (revision 253845) +++ sys/mips/conf/OCTEON1 (working copy) @@ -256,6 +256,7 @@ device wi # WaveLAN/Intersil/Symbol 80 # Pseudo devices. device loop # Network loopback device random # Entropy device +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. Index: sys/mips/conf/PB92 =================================================================== --- sys/mips/conf/PB92 (revision 253845) +++ sys/mips/conf/PB92 (working copy) @@ -22,7 +22,7 @@ options AR71XX_ENV_UBOOT # who already are using it without modifying the default flash layout) # we need to cut down on a lot of things. -makeoptions MODULES_OVERRIDE="ath ath_pci ath_ahb bridgestp if_bridge if_gif if_gre random wlan wlan_acl wlan_amrr wlan_ccmp wlan_rssadapt wlan_tkip wlan_wep wlan_xauth usb ar71xx" +makeoptions MODULES_OVERRIDE="ath ath_pci ath_ahb bridgestp if_bridge if_gif if_gre random yarrow_rng wlan wlan_acl wlan_amrr wlan_ccmp wlan_rssadapt wlan_tkip wlan_wep wlan_xauth usb ar71xx" hints "PB92.hints" include "../atheros/std.ar71xx" Index: sys/mips/conf/RT305X =================================================================== --- sys/mips/conf/RT305X (revision 253845) +++ sys/mips/conf/RT305X (working copy) @@ -24,7 +24,7 @@ makeoptions MIPS_LITTLE_ENDIAN=defined makeoptions KERNLOADADDR=0x80001000 # Don't build any modules yet. -makeoptions MODULES_OVERRIDE="wlan_xauth wlan_wep wlan_tkip wlan_acl wlan_amrr wlan_ccmp wlan_rssadapt random if_bridge bridgestp msdosfs md ipfw dummynet libalias geom/geom_label ufs usb/uplcom usb/u3g usb/umodem usb/umass usb/ucom cam zlib" +makeoptions MODULES_OVERRIDE="wlan_xauth wlan_wep wlan_tkip wlan_acl wlan_amrr wlan_ccmp wlan_rssadapt random yarrow_rng if_bridge bridgestp msdosfs md ipfw dummynet libalias geom/geom_label ufs usb/uplcom usb/u3g usb/umodem usb/umass usb/ucom cam zlib" makeoptions RT3052F include "../rt305x/std.rt305x" @@ -90,6 +90,7 @@ options MROUTING options IPFIREWALL_DEFAULT_TO_ACCEPT device random +options YARROW_RNG # Yarrow software RNG device loop # RT3050F, RT3052F have only pseudo PHYs, so mii not required device rt Index: sys/mips/conf/XLR64 =================================================================== --- sys/mips/conf/XLR64 (revision 253845) +++ sys/mips/conf/XLR64 (working copy) @@ -84,6 +84,7 @@ device uart # Pseudo device loop device random +options YARROW_RNG # Yarrow software RNG device md device bpf Index: sys/mips/conf/XLRN32 =================================================================== --- sys/mips/conf/XLRN32 (revision 253845) +++ sys/mips/conf/XLRN32 (working copy) @@ -85,6 +85,7 @@ device uart # Pseudo device loop device random +options YARROW_RNG # Yarrow software RNG device md device bpf Index: sys/mips/conf/std.SWARM =================================================================== --- sys/mips/conf/std.SWARM (revision 253845) +++ sys/mips/conf/std.SWARM (working copy) @@ -42,6 +42,7 @@ device loop device ether device md device random +options YARROW_RNG # Yarrow software RNG options USB_DEBUG device usb Index: sys/mips/conf/std.XLP =================================================================== --- sys/mips/conf/std.XLP (revision 253845) +++ sys/mips/conf/std.XLP (working copy) @@ -65,6 +65,7 @@ makeoptions FDT_DTS_FILE=xlp-basic.dts # Pseudo device loop device random +options YARROW_RNG # Yarrow software RNG device md device bpf Index: sys/modules/Makefile =================================================================== --- sys/modules/Makefile (revision 253845) +++ sys/modules/Makefile (working copy) @@ -254,6 +254,7 @@ SUBDIR= \ ${_opensolaris} \ oce \ ${_padlock} \ + ${_padlock_rng} \ patm \ ${_pccard} \ ${_pcfclock} \ @@ -280,6 +281,7 @@ SUBDIR= \ ${_random} \ rc4 \ ${_rdma} \ + ${_rdrand_rng} \ re \ reiserfs \ rl \ @@ -363,11 +365,14 @@ SUBDIR= \ ${_x86bios} \ ${_xe} \ xl \ + yarrow_rng \ ${_zfs} \ zlib \ .if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64" _filemon= filemon +_padlock_rng= padlock_rng +_rdrand_rng= rdrand_rng .endif .if ${MACHINE_CPUARCH} != "powerpc" && ${MACHINE_CPUARCH} != "arm" && \ Index: sys/modules/padlock_rng/Makefile =================================================================== --- sys/modules/padlock_rng/Makefile (revision 0) +++ sys/modules/padlock_rng/Makefile (working copy) @@ -0,0 +1,10 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../dev/random + +KMOD= padlock_rng + +SRCS+= \ + nehemiah.c + +.include Property changes on: sys/modules/padlock_rng/Makefile ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: sys/modules/rdrand_rng/Makefile =================================================================== --- sys/modules/rdrand_rng/Makefile (revision 0) +++ sys/modules/rdrand_rng/Makefile (working copy) @@ -0,0 +1,10 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../dev/random + +KMOD= rdrand_rng + +SRCS+= \ + ivy.c + +.include Property changes on: sys/modules/rdrand_rng/Makefile ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Index: sys/modules/yarrow_rng/Makefile =================================================================== --- sys/modules/yarrow_rng/Makefile (revision 0) +++ sys/modules/yarrow_rng/Makefile (working copy) @@ -0,0 +1,19 @@ +# $FreeBSD$ + +.PATH: ${.CURDIR}/../../dev/random +.PATH: ${.CURDIR}/../../crypto/rijndael + +KMOD= yarrow_rng + +SRCS+= \ + hash.c \ + randomdev_soft.c \ + rijndael-alg-fst.c \ + rijndael-api-fst.c \ + yarrow.c + +SRCS+= bus_if.h device_if.h + +CFLAGS+= -I${.CURDIR}/../.. + +.include Property changes on: sys/modules/yarrow_rng/Makefile ___________________________________________________________________ Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Index: sys/pc98/conf/GENERIC =================================================================== --- sys/pc98/conf/GENERIC (revision 253845) +++ sys/pc98/conf/GENERIC (working copy) @@ -217,6 +217,7 @@ options AH_SUPPORT_AR5416 # enable AR54 # Pseudo devices. device loop # Network loopback device random # Entropy device +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. Index: sys/powerpc/conf/GENERIC =================================================================== --- sys/powerpc/conf/GENERIC (revision 253845) +++ sys/powerpc/conf/GENERIC (working copy) @@ -144,6 +144,7 @@ device fxp # Intel EtherExpress PRO/10 # Pseudo devices. device loop # Network loopback device random # Entropy device +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. Index: sys/powerpc/conf/GENERIC64 =================================================================== --- sys/powerpc/conf/GENERIC64 (revision 253845) +++ sys/powerpc/conf/GENERIC64 (working copy) @@ -141,6 +141,7 @@ device fxp # Intel EtherExpress PRO/10 # Pseudo devices. device loop # Network loopback device random # Entropy device +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. Index: sys/powerpc/conf/MPC85XX =================================================================== --- sys/powerpc/conf/MPC85XX (revision 253845) +++ sys/powerpc/conf/MPC85XX (working copy) @@ -76,6 +76,7 @@ device pass device pci device quicc device random +options YARROW_RNG # Yarrow software RNG #device rl device scbus device scc Index: sys/powerpc/conf/WII =================================================================== --- sys/powerpc/conf/WII (revision 253845) +++ sys/powerpc/conf/WII (working copy) @@ -72,6 +72,7 @@ makeoptions SC_DFLT_FONT=cp437 # Pseudo devices. device loop # Network loopback device random # Entropy device +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. Index: sys/sparc64/conf/GENERIC =================================================================== --- sys/sparc64/conf/GENERIC (revision 253845) +++ sys/sparc64/conf/GENERIC (working copy) @@ -215,6 +215,7 @@ device ath_rate_sample # SampleRate tx # Pseudo devices. device loop # Network loopback device random # Entropy device +options YARROW_RNG # Yarrow software RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device tun # Packet tunnel. Index: tools/tools/sysdoc/sysdoc.sh =================================================================== --- tools/tools/sysdoc/sysdoc.sh (revision 253845) +++ tools/tools/sysdoc/sysdoc.sh (working copy) @@ -88,7 +88,7 @@ EOF # tunables in our tunables.mdoc file and generate # the final 'inner circle' of our manual page. markup_create() { - sort < _names | \ + sort -u < _names | \ xargs -n 1 /bin/sh ./sysctl.sh \ > markup.file \ 2> tunables.TODO @@ -238,9 +238,13 @@ if [ -z "$LOCATION" ] ; && for x in `find $LOCATION -name '*.kld'` \ $LOCATION/kernel; \ do nm $x | \ - grep ' sysctl___' | uniq | \ - sed 's/sysctl___//g' | sed 's/_/./g' | \ - awk {'print $3'} > _names; + sed -n '/sysctl___/ { + 's/[\.a-z_]*sysctl___//g' + 's/_/./g' + p + }' | \ + awk {'print $3'} | \ + sort -u > _names; done; markup_create page_create Index: tools/tools/sysdoc/tunables.mdoc =================================================================== --- tools/tools/sysdoc/tunables.mdoc (revision 253845) +++ tools/tools/sysdoc/tunables.mdoc (working copy) @@ -1093,6 +1093,13 @@ line programs. kern.quantum --- +kern.random.adaptors +str + +Displays registered PRNG adaptors (sources). +This is a read-only variable. + +--- kern.random.sys.burst --- -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 18:31:13 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C482CFF; Wed, 7 Aug 2013 18:31:13 +0000 (UTC) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AD0302F22; Wed, 7 Aug 2013 18:31:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r77IVDx8039071; Wed, 7 Aug 2013 18:31:13 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r77IVDw2039068; Wed, 7 Aug 2013 18:31:13 GMT (envelope-from obrien) Date: Wed, 7 Aug 2013 11:31:12 -0700 From: "David O'Brien" To: Philip Paeps Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130807183112.GA79319@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Philip Paeps , secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130731104009.GG59509@rincewind.paeps.cx> X-Mutt-References: <20130731104009.GG59509@rincewind.paeps.cx> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:31:13 -0000 Replying to an earlier comments made: On Wed, Jul 31, 2013 at 12:40:09PM +0200, Philip Paeps wrote: > On 2013-07-29 20:26:27 (+0000), David E. O'Brien wrote: > > New Revision: 253779 > > Log: > > Decouple yarrow from random(4) device. > > * Make Yarrow an optional kernel component -- enabled by > > "YARROW_RNG" option. .. > Of course, we expect > people to read UPDATING, but disabling functionality that has been > enabled by default "forever" without any warning, especially in a > security-related context is not cool. 20120913: The random(4) support for the VIA hardware random number generator (`PADLOCK') is no longer enabled unconditionally. Add the PADLOCK_RNG option in the custom kernel config if needed. The GENERIC kernels on i386 and amd64 do include the option, so the change only affects the custom kernel configurations. This changed a kernel that was secure since 2004-04-09 into less secure one [if you had the right hardware]. So we do have some precedence to look at. Besides the UPDATING file, we also have the release notes for a .0 release. Folks should not be blindly moving to a .0 release with out reading them if they have a custom kernel. There must be some what forward to making changes like this in FreeBSD. I don't recall any other desired changes in the past that simply weren't possible because it would cause someone with a custom kernel a problem. > Please change YARROW_RNG to > RNG_NO_YARROW or something similar and keep it in by default. Given the direction of the patch, I'm don't know how to cleanly inverse logic this. As MarkM has mentioned he's working on another RNG that could be used in place of Yarrow. For $WORK's FIPS-140 and Common Criteria requirements we're working on a NIST SP 800-90-A compliant HMAC_DRBG that we would use instead of Yarrow. > > Unplugging random_adaptor from random(4) is not supported, and is > > probably a bad idea anyway, due to potential loss of entropy > > pools. > > I agree. > But what happens to the adaptors if you kldunload random? The same thing that happens today. We allow the kldunloading of today's random.ko. As noted, kldunloading of the adaptors is disallowed -- their *_modevent() routines MOD_UNLOAD returns EINVAL. This changeset does not change this behavior. This changeset is intended to only be an infrastructure change. > > * If the kernel doesn't have any random_adaptor adapters present > > then the creation of /dev/random is postponed until next > > random_adaptor is kldload'ed. > > This worries me. A fast-booting system might want random numbers in > userland before a random_adaptor is loaded (and properly seeded?). We > don't have particularly stellar support for early random numbers, but we > should be careful not to make it worse. > > Also: what happens to in-kernel consumers of random (like TCP) before > the first random_adaptor is attached (and properly seeded)? What specific routine(s)? When do they first run during boot? If they are called early in boot, the behavior is the same. If they are called late in boot, you get less secure randomness. It is interesting to instrument a GENERIC kernel's arc4rand() and see how many times it is called before becoming more secure: FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 *** random device not loaded; using insecure entropy *** arc4rand(): arc4_randomstir()ed ... Timecounters tick every 1.000 msec *** arc4rand(): Didn't arc4_randomstir() [6 times] ... cd0: Attempt to query device size failed: NOT READY, Medium not present *** arc4rand(): Didn't arc4_randomstir() Trying to mount root from ufs:/dev/ada0s1a [rw,noatime]... *** arc4rand(): Didn't arc4_randomstir() *** random_yarrow_unblock(): arc4rand_iniseed_state set ARC4_ENTR_NONE -> ARC4_ENTR_HAVE *** arc4rand(): arc4_randomstir()ed *** initrandom_start() ... Starting Network: lo0 em0. lo0: flags=8049 metric 0 mtu 16384 -- -- David (obrien@NUXI.org) From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 18:32:43 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B364A1CF; Wed, 7 Aug 2013 18:32:43 +0000 (UTC) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9A1242F36; Wed, 7 Aug 2013 18:32:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r77IWhxA039089; Wed, 7 Aug 2013 18:32:43 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r77IWhuA039086; Wed, 7 Aug 2013 18:32:43 GMT (envelope-from obrien) Date: Wed, 7 Aug 2013 11:32:41 -0700 From: "David O'Brien" To: Pawel Jakub Dawidek Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130807183241.GB79319@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Pawel Jakub Dawidek , secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130802073130.GF5771@garage.freebsd.pl> X-Mutt-References: <20130802073130.GF5771@garage.freebsd.pl> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:32:43 -0000 Replying to an earlier comments made: On Fri, Aug 02, 2013 at 09:31:30AM +0200, Pawel Jakub Dawidek wrote: > Not to mention that hardware RNGs are often hard to trust. I think Intel > refused to publish RDRAND specs? No argument there. I know some folks feel RDRAND could be tainted for NSA's sake. > With PRNG in place you get consistent performance, it is seeded from > various different sources (hardware RNG being one of them), so it is This isn't correct. If you have hardware RNG today, you use it instead of software RNG. The HW-RNG is not an entropy source into Yarrow. Another thing we're fixing if we can get past this infrastructure change. -- -- David (obrien@NUXI.org) From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 18:35:18 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 86A5F3B0; Wed, 7 Aug 2013 18:35:18 +0000 (UTC) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6C9392F5D; Wed, 7 Aug 2013 18:35:18 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r77IZI6I039160; Wed, 7 Aug 2013 18:35:18 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r77IZHM7039157; Wed, 7 Aug 2013 18:35:17 GMT (envelope-from obrien) Date: Wed, 7 Aug 2013 11:35:16 -0700 From: "David O'Brien" To: Scott Long Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130807183516.GC79319@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Scott Long , secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0E0C0EEC-A7DA-4802-A683-E2ADD9D47A19@yahoo.com> X-Mutt-References: <0E0C0EEC-A7DA-4802-A683-E2ADD9D47A19@yahoo.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:35:18 -0000 Replying to an earlier comments made: On Mon, Aug 05, 2013 at 09:42:51PM -0600, Scott Long wrote: > > OK - so we are agreed that obrien@'s commit didn't break anything? > > It absolutely broke something. It rendered my remote test machines useless > after what should have been a routine source upgrade. Even figuring > out what happened and mashing on the remote keyboard only succeeded in > making the machines limp forward with no /dev/random device. Hi Scott, Please give more detail about the issue if you can. I would really like to understand how the changeset negatively impacted you in order to fix the issue. I have used this changeset on headless machines (so no keyboard or mouse entropy) with both GENERIC kernel and a kernel without RANDOM. For kernel without RANDOM I even waited until I had a login prompt to load the ko's in order to test having no /dev/random until fully multi-user. -- -- David (obrien@NUXI.org) From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 18:52:36 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B2B2A9CA for ; Wed, 7 Aug 2013 18:52:36 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6F1DC207F for ; Wed, 7 Aug 2013 18:52:36 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id pb11so2250302veb.11 for ; Wed, 07 Aug 2013 11:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=3GktjJ8TKDNtNgHYKRJ+d19m/UdxdTVZwRmItNTj0d8=; b=LDwn5KUf1aOtQI3HyILdreh9By3F+L23riRiF7qMn3xL8s9zyaU61+wlD2DpJGczjh Rwl/taa/VB4CaeF1qitfIzk7Pi2069oU5Uu+/xOZLuYxfB5yXC7s8hKHp8m4iCb1zYhq v7WyqDWCzIkgFkVWwhZ5pIT/nQmdJ7hdvcQ4I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=3GktjJ8TKDNtNgHYKRJ+d19m/UdxdTVZwRmItNTj0d8=; b=RImnJBXAVoN8MvDWij9SUvxFQgOPhOD+9KIAwLB2Ag4rqFrHHLt0aoaXjYPh/KZlCL pNr0z7rYLTD7sOI4828KyTa6EFek9pnJLypMZ3YyuPozuhsffXzrzjDdETh9zh3q7hX1 MkkAnh5EZN3475fPJz7Fa2yhGdaHhlxuuFR9DRjM9qK6/NqdBLBpKobOEqK81LnZVi0z LFkAlCm2yHwnIi1Yp2KEZavosXCZKSc0NsIocZwzVM4C9QtGx7nWWwSs74vqyDiEe3m7 ft0YpsjSVphL/b3K1if05C0Ex4kqUr1Zq+KPGKU5f2Ig1bwr8hHXi6nNzqa+gQhQGpsg H+Ag== X-Gm-Message-State: ALoCoQk6AhZVr4Oh1cRehz40qvRqQCNhjef1yGzbiTGwzTBDhhpsFSKRUBVZbV2KVNEeuXoh7UCB MIME-Version: 1.0 X-Received: by 10.52.37.8 with SMTP id u8mr980048vdj.73.1375901555593; Wed, 07 Aug 2013 11:52:35 -0700 (PDT) Received: by 10.220.167.74 with HTTP; Wed, 7 Aug 2013 11:52:35 -0700 (PDT) In-Reply-To: <20130807183112.GA79319@dragon.NUXI.org> References: <20130731104009.GG59509@rincewind.paeps.cx> <20130807183112.GA79319@dragon.NUXI.org> Date: Wed, 7 Aug 2013 11:52:35 -0700 Message-ID: Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion From: Peter Wemm To: obrien@freebsd.org, Philip Paeps , secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:52:36 -0000 On Wed, Aug 7, 2013 at 11:31 AM, David O'Brien wrote: [..] >> Please change YARROW_RNG to >> RNG_NO_YARROW or something similar and keep it in by default. > > Given the direction of the patch, I'm don't know how to cleanly inverse > logic this. If you were going to go this route you would put "options YARROW_RNG" into $ARCH/conf/DEFAULTS and let people disable it with 'nooptions YARROW_RNG'. 'device random' should probably be a default option alongside it too though given how badly things fail without it. Especially given: > * If the kernel doesn't have any random_adaptor adapters present then the > creation of /dev/random is postponed until next random_adaptor is kldload'ed. Postponing can't really be done. That's a good way to remotely brick a machine. I'd be more inclined to have it be a panic offense if 'device random' is present with no sources. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 18:53:33 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 84E48A8F; Wed, 7 Aug 2013 18:53:33 +0000 (UTC) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 69E39208E; Wed, 7 Aug 2013 18:53:33 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r77IrXwW042640; Wed, 7 Aug 2013 18:53:33 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r77IrX4D042637; Wed, 7 Aug 2013 18:53:33 GMT (envelope-from obrien) Date: Wed, 7 Aug 2013 11:53:32 -0700 From: "David O'Brien" To: Peter Wemm , Adrian Chadd Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130807185332.GA79570@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Peter Wemm , Adrian Chadd , secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh References: <201307292058.r6TKwA56031193@svn.freebsd.org> <86mwp3f4k5.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT X-MUA-Host: dragon.NUXI.org X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:53:33 -0000 [Choosing one of the "blocking" related emails to reply to] On Fri, Aug 02, 2013 at 12:00:40AM -0700, Peter Wemm wrote: > On Wed, Jul 31, 2013 at 11:07 AM, Adrian Chadd wrote: > > Should David's patch print a louder warning if no hardware RNG is > > registered? I don't thing it would improve things -- but only give the false impression random(4) is working well and secure. (see below) > Secure randomness is vital - we've seen other projects take a massive > hit over this. I'd be inclined to make this a showstopper. We > certainly shouldn't allow things like ssh-keygen or sshd to start up. While I don't disagree -- this is a major change from today's FreeBSD kernel. So I don't feel it should be a road block to making these infrastructure chagnes. I don't think folks realize just how bad things are. I communicated this last September when I tried to do some things in this area and got shouted down. I've seen no one work on this area for the past year. Thus at $WORK we're trying to improve our random(4). We are able to fully boot and produce keys without being seeded, and without generating any entropy. Try booting a kernel without "device random" and see how the system runs, doesn't block, nor give any indication of lack of /dev/random. Apply the patch below and boot a kernel and see how there is no blocking or other indication of running in a less secure manner. This changeset does not address that, nor do I think these issues should block what is basically an infrastructure change. -- -- David (obrien@FreeBSD.org) Index: sys/dev/random/harvest.c =================================================================== --- sys/dev/random/harvest.c (revision 253802) +++ sys/dev/random/harvest.c (working copy) @@ -48,7 +48,13 @@ __FBSDID("$FreeBSD$"); static int read_random_phony(void *, int); /* Structure holding the desired entropy sources */ -struct harvest_select harvest = { 1, 1, 1, 0 }; +struct harvest_select harvest = { + 0, /*ethernet*/ + 0, /*pt2pt*/ + 0, /*intr*/ + 0, /*swi*/ + /**/ +}; static int warned = 0; /* hold the address of the routine which is actually called if Index: sys/dev/random/randomdev_soft.c =================================================================== --- sys/dev/random/randomdev_soft.c (revision 253802) +++ sys/dev/random/randomdev_soft.c (working copy) @@ -74,7 +75,7 @@ struct random_adaptor random_yarrow = { .write = random_yarrow_write, .poll = random_yarrow_poll, .reseed = random_yarrow_flush_reseed, - .seeded = 1, + .seeded = 0, }; MALLOC_DEFINE(M_ENTROPY, "entropy", "Entropy harvesting buffers"); @@ -135,7 +162,7 @@ random_yarrow_init(void) SYSCTL_ADD_PROC(&random_clist, SYSCTL_CHILDREN(random_sys_o), OID_AUTO, "seeded", CTLTYPE_INT | CTLFLAG_RW, - &random_yarrow.seeded, 1, random_check_boolean, "I", + &random_yarrow.seeded, 0, random_check_boolean, "I", "Seeded State"); random_sys_harvest_o = SYSCTL_ADD_NODE(&random_clist, From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 18:56:59 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7AFBED3E; Wed, 7 Aug 2013 18:56:59 +0000 (UTC) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 635FF20AF; Wed, 7 Aug 2013 18:56:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r77IuxxI042719; Wed, 7 Aug 2013 18:56:59 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r77Iuw5q042716; Wed, 7 Aug 2013 18:56:58 GMT (envelope-from obrien) Date: Wed, 7 Aug 2013 11:56:57 -0700 From: "David O'Brien" To: Fabien Thomas Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130807185657.GB79570@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Fabien Thomas , secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh References: <201307292026.r6TKQRRb021717@svn.freebsd.org> <5E61D610-3322-4240-9978-CB277C7161F5@netasq.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E61D610-3322-4240-9978-CB277C7161F5@netasq.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 18:56:59 -0000 On Fri, Aug 02, 2013 at 10:05:57AM +0200, Fabien Thomas wrote: > We need to have very good random by default. Even selecting HW random > automatically is not very good. HW random is difficult to trust. > > Why not having a good default software random seeded by automatically > detected HW random ? After that the user can choose to bypass the > software random a feed directly by the HW random source. Please don't hijack an infrastructure change that changes nothing for the GENERIC kernel. Please start a separate thread about changing how HW random sources are handled in random(4) if you like. But that is outside the scope of this change. [Adding flexibility to how the HW sources are used will be in one of our next proposed changes.] -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 19:02:26 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D412D193 for ; Wed, 7 Aug 2013 19:02:26 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8FBA12140 for ; Wed, 7 Aug 2013 19:02:26 +0000 (UTC) Received: by mail-ve0-f174.google.com with SMTP id d10so2226479vea.5 for ; Wed, 07 Aug 2013 12:02:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Qo7FBhJiHg+kgdPc26H6z3gJSTEx9VjRxTDeiW7m2TE=; b=JCoyrpoMay6o31olwBw7RntS1CZIUn0R8o4SMjGy6rvws85rA1xGQ/YPUXBVTcnwFL 96WMnASPCvN52Hhp1XhFWwSPoqeYijrYRxjwHen9vYhbwAZhjDRx3tKu91MFJ9CHOw7d RBtaU5vkfiXjCplaWtYf29kI10oSmOKfLeR7c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=Qo7FBhJiHg+kgdPc26H6z3gJSTEx9VjRxTDeiW7m2TE=; b=gEUQ8CvE0YPEskF/O4WhoFMMie1dnT09iEMPXCe+Qndky0WUUf4IMahS+ceKo+qbbz 4ofHfLaUSrjCfbPfN6CO/dA+l4oHRlxJAiQ/MQiIdZh3Aqh9aM/Pj9AXtnaMplbQ0gPZ 5LEsdDaKkjWOLnp2bYdlI/M0zL/pn2vdn2kCiFZB4Bsczx77TFulVrWsOavqskniYV0Z mWGuDYmB9OuOP2iKzYTUnYGmYbAbGc6ZMcRE7ZAiSchqrAJ0BXMt4yEm8new2uBLiPgL ReYMH3E379GOT/NGdo4KmERb/4yiRtMEkY6NJy1DR78YqcoRNDq4iW8SJijw+/s0Griq 4fng== X-Gm-Message-State: ALoCoQmxdBpkC2uyU+0Rcyr9wBBUEQPwR+m0hMPH4pydqv2c6AWHUoA5xaN3QjZ9/0GNRca9a0hK MIME-Version: 1.0 X-Received: by 10.52.191.72 with SMTP id gw8mr990762vdc.114.1375902145659; Wed, 07 Aug 2013 12:02:25 -0700 (PDT) Received: by 10.220.167.74 with HTTP; Wed, 7 Aug 2013 12:02:25 -0700 (PDT) In-Reply-To: <20130807185657.GB79570@dragon.NUXI.org> References: <201307292026.r6TKQRRb021717@svn.freebsd.org> <5E61D610-3322-4240-9978-CB277C7161F5@netasq.com> <20130807185657.GB79570@dragon.NUXI.org> Date: Wed, 7 Aug 2013 12:02:25 -0700 Message-ID: Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion From: Peter Wemm To: obrien@freebsd.org, Fabien Thomas , secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 19:02:26 -0000 On Wed, Aug 7, 2013 at 11:56 AM, David O'Brien wrote: > On Fri, Aug 02, 2013 at 10:05:57AM +0200, Fabien Thomas wrote: >> We need to have very good random by default. Even selecting HW random >> automatically is not very good. HW random is difficult to trust. >> >> Why not having a good default software random seeded by automatically >> detected HW random ? After that the user can choose to bypass the >> software random a feed directly by the HW random source. > > Please don't hijack an infrastructure change that changes nothing for the > GENERIC kernel. The problem people have isn't with GENERIC.. its the less than optimal effect this change causes on custom kernel configs. ie: a magnitude 10 POLA violation. > Please start a separate thread about changing how HW random sources are > handled in random(4) if you like. But that is outside the scope of > this change. > > [Adding flexibility to how the HW sources are used will be in one of our > next proposed changes.] Please don't hold future "do it right" changes hostage to an interim "break things by default" change. If you're going somewhere with this, how about we skip the "broken by default" step and see where you're going? -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 19:19:22 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C281C80B; Wed, 7 Aug 2013 19:19:22 +0000 (UTC) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A79D22265; Wed, 7 Aug 2013 19:19:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r77JJMWL047530; Wed, 7 Aug 2013 19:19:22 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r77JJLKP047527; Wed, 7 Aug 2013 19:19:21 GMT (envelope-from obrien) Date: Wed, 7 Aug 2013 12:19:21 -0700 From: "David O'Brien" To: Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130807191921.GA80078@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Dag-Erling =?unknown-8bit?B?U23DuHJncmF2?= , secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh References: <201307292058.r6TKwA56031193@svn.freebsd.org> <86fvuwgrs6.fsf@nine.des.no> <20130730185034.GA63635@dragon.NUXI.org> <86zjt3f4zk.fsf@nine.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86zjt3f4zk.fsf@nine.des.no> X-Operating-System: FreeBSD 10.0-CURRENT X-MUA-Host: dragon.NUXI.org X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 19:19:22 -0000 Replying to an earlier comments made: On Wed, Jul 31, 2013 at 11:33:51AM +0200, Dag-Erling Smrgrav wrote: > - The non-standard (at least in an IT context) spelling of "adapter". The spelling "adaptor" was chosen vs. "adapter" as Adapter: A Person who adapt to a certain situation. Adaptor: An Inanimate object designed to adapt one thing to another. This may be more of a UK vs. USA English thing. If the naming is a roadblock we can change it. But it is nice being able to grep for unique strings. :-) -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 19:27:42 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C7B34A17; Wed, 7 Aug 2013 19:27:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A797C2319; Wed, 7 Aug 2013 19:27:42 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r77JRabm007148; Wed, 7 Aug 2013 12:27:36 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r77JRaoc007147; Wed, 7 Aug 2013 12:27:36 -0700 (PDT) (envelope-from sgk) Date: Wed, 7 Aug 2013 12:27:36 -0700 From: Steve Kargl To: obrien@freebsd.org, secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130807192736.GA7099@troutmask.apl.washington.edu> References: <20130807182858.GA79286@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130807182858.GA79286@dragon.NUXI.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 19:27:42 -0000 On Wed, Aug 07, 2013 at 11:28:58AM -0700, David O'Brien wrote: > > * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" > option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c > comprise yarrow. random(4) device doesn't really depend on > rijndael-*. Yarrow, however, does. > > * If the kernel doesn't have any random_adaptor adapters present then > the creation of /dev/random is postponed until next random_adaptor > is kldload'ed. My kernel config files have included the following 2 lines for ages: makeoptions NO_MODULES device random If I try to build a new kernel under your scheme, will the build die with an error about a missing option? If the answer is 'no', then the yarrow adaptor should be opt-out. -- steve From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 20:19:52 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 04288D00; Wed, 7 Aug 2013 20:19:52 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BDEA02696; Wed, 7 Aug 2013 20:19:51 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id D65671203E0; Wed, 7 Aug 2013 22:19:34 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id BF79B28494; Wed, 7 Aug 2013 22:19:34 +0200 (CEST) Date: Wed, 7 Aug 2013 22:19:34 +0200 From: Jilles Tjoelker To: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= Subject: Re: Reliable process tracking Message-ID: <20130807201934.GA4918@stack.nl> References: <20130804134658.GC35080@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:19:52 -0000 On Mon, Aug 05, 2013 at 01:13:10PM +0200, Edward Tomasz Napierała wrote: > Wiadomość napisana przez Jilles Tjoelker w dniu 4 sie 2013, o godz. 15:46: > > When shutting down a service or requesting status, rc.subr currently > > uses a combination of pidfiles and process names. This is fairly but not > > completely reliable once it is set up correctly (which can take a lot of > > work and possibly patching the daemon to use pidfile(3) from our > > libutil). It is also incapable of killing multiprocess daemons such as > > CGI web servers without cooperation of the daemon. > > I think what is needed here is a facility that marks a process and all > > of its descendants. Removing the mark should be a privileged or at least > > an unusual operation; no unprivileged function specified by POSIX such > > as setsid() should do this. > I've actually thought about that when I added setloginclass(2). It's > trivial to modify rc.subr to use su(8) to set login class for each > service. It should be trivial to modify pkill(1) and killall(1) to > add "-c" option to kill all processes in a given login class. There are some problems with su -c: * It refuses to set a login class name that is not in /etc/login.conf. Given that multiple instances of a service should each have their own kernel login class, it may make sense to allow specifying the login.conf entry separate from the kernel login class. * It always inserts an intermediate process to shut down the PAM session. This is not needed to start a simple daemon but not that harmful apart from performance. > Two caveats: > 1. Login classes, just like UIDs, are global, not per jail. This means when > you want to kill all processees in a login class, you should probably use > "-j" option to limit it to a given jail, e.g. jail 0. True. > 2. I'm not sure if pkill(1) has any special way of handling this, but there is > an obvious race condition between iterating over processes in userland > in pkill(1) and quickly forking processes to kill. Perhaps we should have > some kind of syscall to do it in a race-free way? Yes. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Wed Aug 7 20:20:31 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4D9D3DB4 for ; Wed, 7 Aug 2013 20:20:31 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E3A6626C3 for ; Wed, 7 Aug 2013 20:20:30 +0000 (UTC) Received: by mail-ve0-f178.google.com with SMTP id ox1so2367958veb.9 for ; Wed, 07 Aug 2013 13:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f5LvDSXfLs/1J8/ErS5aF3rylxhEoKl03gcM6RHc24Q=; b=RcH38WnhjtKJ1GEdxvIjqr4dmS5rIIXdNq1hog0EIRzzC/QQf2b0x24cnK8NmTSvNW w0u62Ec/Iy60a+JXGIaCzvhFUVeOmwPnhlPeWpUy+XJxs3m1Ihhwu+b/cWJsl3z8A8Wx vBM5GnAl3wUwh0FsPWSarC8BamBlcbCRe2xQ0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=f5LvDSXfLs/1J8/ErS5aF3rylxhEoKl03gcM6RHc24Q=; b=o2olnoeZoJUYjJUVx33qr6EQOlJATHBDjs4QkvhdF21DSc6J3ujLtPqDW1/ZOa7q0O o6JNnsIyl2UkVMUljPuGrXXMY0Rp0YHeeQ/btja0YL5rDFDn8wql9dpI6pGS1a+Uslcs dbKkAqJ+n+OyQPNlAYiiflW3RzEclPHTimrPalVeBr4H3DmS9KHLYRdbJQfzIZPpV6BS 2IfQIU1cNyoYW6m9ajrFT6NMBFa2704Ao+hf6Z+ookvwSy65HU7f5QbmgyrEyHmY+nS4 vjieHetTRb4uFQX2ENPnn2SRpovIn1M3HFlXt3pJTzKuBJFmjy7ubM/8dDNA1kb0aP69 c08g== X-Gm-Message-State: ALoCoQmrRQ3yauKJfJp0BgGra6//TdZOZfYVw4FapDerqJqteLf70uoOEQPbA4j449NzvjJWMtAf MIME-Version: 1.0 X-Received: by 10.52.191.72 with SMTP id gw8mr1139293vdc.114.1375906830055; Wed, 07 Aug 2013 13:20:30 -0700 (PDT) Received: by 10.220.167.74 with HTTP; Wed, 7 Aug 2013 13:20:29 -0700 (PDT) In-Reply-To: <20130807192736.GA7099@troutmask.apl.washington.edu> References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> Date: Wed, 7 Aug 2013 13:20:29 -0700 Message-ID: Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion From: Peter Wemm To: Steve Kargl Content-Type: text/plain; charset=ISO-8859-1 Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2013 20:20:31 -0000 On Wed, Aug 7, 2013 at 12:27 PM, Steve Kargl wrote: > On Wed, Aug 07, 2013 at 11:28:58AM -0700, David O'Brien wrote: >> >> * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" >> option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c >> comprise yarrow. random(4) device doesn't really depend on >> rijndael-*. Yarrow, however, does. >> >> * If the kernel doesn't have any random_adaptor adapters present then >> the creation of /dev/random is postponed until next random_adaptor >> is kldload'ed. > > My kernel config files have included the following 2 lines for > ages: > > makeoptions NO_MODULES > device random > > If I try to build a new kernel under your scheme, will the > build die with an error about a missing option? If the answer > is 'no', then the yarrow adaptor should be opt-out. That's the main point here. If I'm running on a working system, I have a reasonable expectation that the kernel config I was using yesterday will work sufficiently tomorrow that I won't get hosed by doing a 'svn update && make buildkernel && make installkernel'. If that's not the case and there is a required change in order to not hose your system then POLA dictates that not making the required changes causes a build failure. There's more leeway on head than a stable branch, but remember that when people upgrade from 9.x to 10.x they tend to take their 9.x kernel configs and make whatever changes are needed to get it to build. The 9-stable -> 10-release config path needs to catch fatal errors like this at build time. Patching GENERIC isn't a complete solution. It doesn't solve the 'yesterday it worked, today it's a brick' problem. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 00:07:23 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7215E290 for ; Thu, 8 Aug 2013 00:07:23 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm22-vm2.bullet.mail.ne1.yahoo.com (nm22-vm2.bullet.mail.ne1.yahoo.com [98.138.91.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 35B6924D3 for ; Thu, 8 Aug 2013 00:07:23 +0000 (UTC) Received: from [98.138.101.131] by nm22.bullet.mail.ne1.yahoo.com with NNFMP; 08 Aug 2013 00:07:16 -0000 Received: from [98.138.226.31] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 08 Aug 2013 00:07:16 -0000 Received: from [127.0.0.1] by smtp202.mail.ne1.yahoo.com with NNFMP; 08 Aug 2013 00:07:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1375920436; bh=Lp4/svUQV+gvX4nSwPs9erg8jeampy7iK4DOj3uMTFE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=V1U6j+u8rhzFUuJotVX6PKKi2DQvQm8QfmPXtffOi++zfMj6vKafNaFqVhwZOy/S1HbNXyZCMMpc6Tvfxjtz1FvsgYNQ2MAJvNkW3FOK5PB7XAxTpa2hk5aYFcRpXx431Z1UJ/k8j1DzimEg/U/eYs+59zKEHrooRiDZfzgJwss= X-Yahoo-Newman-Id: 170666.87593.bm@smtp202.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zI9jHzEVM1ll2OHyLVh.pkJgY3ahKjHMbt440ApbrOnoum_ QRtWAFuCdSkwkzWc8FJyQMGQ_mgGpcSIdGVrvI_gKX2ACKIoI6zWwoAl0XKW dxms2UgTIge3CxKnSBND6YNvhlmsQLmb40Gt4lNa.lMdTUVmTNAPA8lUjEiO RgGKJB3vc5uMGMgQ9x4fWYOLh6eP9yn5V41pCzz.78CdRjObXgZ0v_SCTFY2 PxlqN.0lzJSe6269SeaB.dds59xcNGmX7VHbcvzv7TngN3z.VWaoVb4Jyjxs SfSlLhXM3mhP2muUEld059Egx4O6XKzW.5.vVZrj1Ld13Jw_1Z0jeKjGBPYr IhZYl5eYU7nKxJ7cZ3iT6gGrdPxTYTUGdL4piS.vNXONLYjmzDyv0JpWZklP RMv5mxaltJ68rMISECFSbe.X4.CKq9tvL48X6JsS8v1p8tEDz7_oIvbweTUk UdfmAM3XXI.4e5rL0RFpobWdcljFrr3SSSgdFp5A7BtFQWcz83PR2pPur_Da ZxzPwgDio0KpoZ78Cc7BMblyJfHe.NrVNNp7nb2QK2YR1SU.lYZncV5gpLyT j.w-- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from phobos.corp.netflix.com (scott4long@69.53.237.66 with ) by smtp202.mail.ne1.yahoo.com with SMTP; 07 Aug 2013 17:07:16 -0700 PDT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion From: Scott Long In-Reply-To: <20130807183516.GC79319@dragon.NUXI.org> Date: Wed, 7 Aug 2013 17:07:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1EDB5C8E-5755-4A8A-89F1-A64412080744@yahoo.com> References: <20130807183516.GC79319@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1508) Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 00:07:23 -0000 On Aug 7, 2013, at 11:35 AM, David O'Brien wrote: > Replying to an earlier comments made: >=20 > On Mon, Aug 05, 2013 at 09:42:51PM -0600, Scott Long wrote: >>> OK - so we are agreed that obrien@'s commit didn't break anything? >>=20 >> It absolutely broke something. It rendered my remote test machines = useless >> after what should have been a routine source upgrade. Even figuring >> out what happened and mashing on the remote keyboard only succeeded = in >> making the machines limp forward with no /dev/random device. >=20 > Hi Scott, > Please give more detail about the issue if you can. I would really = like > to understand how the changeset negatively impacted you in order to = fix > the issue. >=20 We only compile and deploy a whitelist subset of modules, so the PRNG modules were not compiled into the kernel nor present in /boot. When = the machine came up, it paused waiting for keyboard input. In one = iteration, it released the hold after about 100 characters of quick typing. In = another iteration, it waited as I slowly typed only a few characters a minute, = until I gave up. In a third iteration, it waited indefinitely as I typed = nothing, and I gave up after 5-10 minutes. In the first iteration, even after the system continued, various things = complained and/or failed with a complaint of there being no /dev/random. named was = one thing, but I know there were others. We've since moved on and picked up the post-revert sources. Scott From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 05:36:54 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 29933493 for ; Thu, 8 Aug 2013 05:36:54 +0000 (UTC) (envelope-from uebayasi@gmail.com) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B221D269A for ; Thu, 8 Aug 2013 05:36:53 +0000 (UTC) Received: by mail-bk0-f47.google.com with SMTP id mx12so511855bkb.6 for ; Wed, 07 Aug 2013 22:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6vNUKFe4cWqUGngM2uobAxgG22ndyjrzUcjS34Vj9Qc=; b=tP9mokOPqipR95Kl+Af5Duzgni/hAxcERsbql8SbqGMx+0qBIQuDwpnqXqqLFd2H5k YN3idOCZpw2xjx4vzNIpThpjGJsc7aLlZccR5dt5D5IdUOxadSkAD/z2DVN5ZnaErpjq XIuDQ6Jq35nM/B3k/2V7sOI1OP4CnkKmDCg3TGtH8QST2/qrmNNIw89oZbFM5PkiWe/d qsEtdTDdD0Iaedr/aSavYTi4n4CBc6i7UYlIhMSVR+zGcPbaasSrGW1aQJR5RJ10t8Ye 4tkfF/00Ojsg1mAg9GfptDO3lt+kADWgg6nbetTMWYKpSkHU2boSxkHGlPmhzWN+kNY8 bujg== MIME-Version: 1.0 X-Received: by 10.205.15.7 with SMTP id ps7mr991038bkb.45.1375940211834; Wed, 07 Aug 2013 22:36:51 -0700 (PDT) Received: by 10.205.36.9 with HTTP; Wed, 7 Aug 2013 22:36:51 -0700 (PDT) Date: Thu, 8 Aug 2013 14:36:51 +0900 Message-ID: Subject: panic(9) vs. RB_NOSYNC From: Masao Uebayashi To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 05:36:54 -0000 panic(9) (actually vpanic()) sets RB_NOSYNC when panicstr is already set. What is the reasoning of this? My understanding is that panic() attempts VFS "sync" operation at first. If another panic() is triggered during that, give up VFS "sync". Is this correct? If so, how reliable is this design? I wonder if attempting such a complex task like VFS "sync" after a panic is a good idea. From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 13:01:06 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id ABFAE322 for ; Thu, 8 Aug 2013 13:01:06 +0000 (UTC) (envelope-from mailer-daemon@vniz.net) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3DF72208B for ; Thu, 8 Aug 2013 13:01:05 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id en1so538746wid.0 for ; Thu, 08 Aug 2013 06:01:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=HrIEx+MXBSmAEiIIfaT7uI5Xq2VaV/qaiCztF+3BpOc=; b=DtL57IxM1DcVAGnCNDJXBgallOfXxDJrs6sjTaySS85cP1l1XQpklz3H4le+c4MWxY g9dmUXNHPyPbhMdpd2HXgNY5U9Fqrs7n2Z98uRdhOYGh6+flS26ADKpPbA9+aNhNIKXJ CbyvONxwKZGForkWh8WTDMJ92gkJHgmd/i5RdQ81lT6DAMt6lS5vSxvVmsd/AEVW28TV fWaVLp2t9kZttsrcC9j5bKe8/HnMJnPK6DnrupM+NrODjaP7NpYWPyAHS66AB/406doY zimhRU5Je85Om4PwdPdy1OtYAe7TdR3lj8TynVbbQ421BUlz/4V9DOqVqLs83Y3yt2i/ /Nbg== X-Gm-Message-State: ALoCoQkS1LeSZQntzpr9cWDEpdWHuBN03MYhJRg+rVCJbmamckn/rtOrb1cz6G4fUFAe3Of/elMV X-Received: by 10.180.37.20 with SMTP id u20mr5015708wij.21.1375966863933; Thu, 08 Aug 2013 06:01:03 -0700 (PDT) Received: from [192.168.1.2] ([89.169.173.68]) by mx.google.com with ESMTPSA id l5sm14495766wia.6.2013.08.08.06.01.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 06:01:03 -0700 (PDT) Message-ID: <5203968D.7060508@freebsd.org> Date: Thu, 08 Aug 2013 17:01:01 +0400 From: Andrey Chernov User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Peter Wemm Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> In-Reply-To: OpenPGP: id=964474DD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Arthur Mesh , secteam@freebsd.org, Steve Kargl , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 13:01:06 -0000 On 08.08.2013 0:20, Peter Wemm wrote: > That's the main point here. > > If I'm running on a working system, I have a reasonable expectation > that the kernel config I was using yesterday will work sufficiently > tomorrow that I won't get hosed by doing a 'svn update && make > buildkernel && make installkernel'. > > If that's not the case and there is a required change in order to not > hose your system then POLA dictates that not making the required > changes causes a build failure. > > There's more leeway on head than a stable branch, but remember that > when people upgrade from 9.x to 10.x they tend to take their 9.x > kernel configs and make whatever changes are needed to get it to > build. The 9-stable -> 10-release config path needs to catch fatal > errors like this at build time. > > Patching GENERIC isn't a complete solution. It doesn't solve the > 'yesterday it worked, today it's a brick' problem. Many years ago I already suggest to de-modularize random (making it not optional), with fallback to yarrow if hardware RNGs can't be probed or not configured. -- http://ache.vniz.net/ bitcoin:1G6ugdNY6e5jx1GVnAU2ntj2NEfmjKG85r From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 14:48:03 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id A4F147F1; Thu, 8 Aug 2013 14:48:03 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A277282E; Thu, 8 Aug 2013 14:48:03 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 55D6EB962; Thu, 8 Aug 2013 10:48:02 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Date: Thu, 8 Aug 2013 10:23:52 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308081023.53040.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 08 Aug 2013 10:48:02 -0400 (EDT) Cc: Arthur Mesh , secteam@freebsd.org, Steve Kargl X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 14:48:03 -0000 On Wednesday, August 07, 2013 4:20:29 pm Peter Wemm wrote: > On Wed, Aug 7, 2013 at 12:27 PM, Steve Kargl > wrote: > > On Wed, Aug 07, 2013 at 11:28:58AM -0700, David O'Brien wrote: > >> > >> * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" > >> option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c > >> comprise yarrow. random(4) device doesn't really depend on > >> rijndael-*. Yarrow, however, does. > >> > >> * If the kernel doesn't have any random_adaptor adapters present then > >> the creation of /dev/random is postponed until next random_adaptor > >> is kldload'ed. > > > > My kernel config files have included the following 2 lines for > > ages: > > > > makeoptions NO_MODULES > > device random > > > > If I try to build a new kernel under your scheme, will the > > build die with an error about a missing option? If the answer > > is 'no', then the yarrow adaptor should be opt-out. > > That's the main point here. > > If I'm running on a working system, I have a reasonable expectation > that the kernel config I was using yesterday will work sufficiently > tomorrow that I won't get hosed by doing a 'svn update && make > buildkernel && make installkernel'. > > If that's not the case and there is a required change in order to not > hose your system then POLA dictates that not making the required > changes causes a build failure. > > There's more leeway on head than a stable branch, but remember that > when people upgrade from 9.x to 10.x they tend to take their 9.x > kernel configs and make whatever changes are needed to get it to > build. The 9-stable -> 10-release config path needs to catch fatal > errors like this at build time. > > Patching GENERIC isn't a complete solution. It doesn't solve the > 'yesterday it worked, today it's a brick' problem. The counter to this is that in the recent past, any suggestion to add anything to DEFAULTS was met with "that's the wrong way". In actual fact, changes to GENERIC happen quite often, and we often break older kernel configs from older branches (ATA_CAM is no longer in 10 for example). I'm not sure I buy the argument that we can never break kernel configs from older branches. I also think that NO_FOO options aren't the way to go and that we should always create "positive" options, but add them to GENERIC when making a previously standard thing optional. I think adding things to DEFAULTS should be rarely done, if ever. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 15:48:29 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6A9367FD; Thu, 8 Aug 2013 15:48:29 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4DD9D2DB9; Thu, 8 Aug 2013 15:48:29 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.6/8.14.6) with ESMTP id r78FmSUI021781; Thu, 8 Aug 2013 08:48:28 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.6/8.14.6/Submit) id r78FmSOi021780; Thu, 8 Aug 2013 08:48:28 -0700 (PDT) (envelope-from sgk) Date: Thu, 8 Aug 2013 08:48:28 -0700 From: Steve Kargl To: John Baldwin Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130808154828.GA21740@troutmask.apl.washington.edu> References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <201308081023.53040.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201308081023.53040.jhb@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 15:48:29 -0000 On Thu, Aug 08, 2013 at 10:23:52AM -0400, John Baldwin wrote: > On Wednesday, August 07, 2013 4:20:29 pm Peter Wemm wrote: > > On Wed, Aug 7, 2013 at 12:27 PM, Steve Kargl > > wrote: > > > On Wed, Aug 07, 2013 at 11:28:58AM -0700, David O'Brien wrote: > > >> > > >> * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" > > >> option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c > > >> comprise yarrow. random(4) device doesn't really depend on > > >> rijndael-*. Yarrow, however, does. > > >> > > >> * If the kernel doesn't have any random_adaptor adapters present then > > >> the creation of /dev/random is postponed until next random_adaptor > > >> is kldload'ed. > > > > > > My kernel config files have included the following 2 lines for > > > ages: > > > > > > makeoptions NO_MODULES > > > device random > > > > > > If I try to build a new kernel under your scheme, will the > > > build die with an error about a missing option? If the answer > > > is 'no', then the yarrow adaptor should be opt-out. > > > > That's the main point here. > > > > If I'm running on a working system, I have a reasonable expectation > > that the kernel config I was using yesterday will work sufficiently > > tomorrow that I won't get hosed by doing a 'svn update && make > > buildkernel && make installkernel'. > > > > If that's not the case and there is a required change in order to not > > hose your system then POLA dictates that not making the required > > changes causes a build failure. > > > > There's more leeway on head than a stable branch, but remember that > > when people upgrade from 9.x to 10.x they tend to take their 9.x > > kernel configs and make whatever changes are needed to get it to > > build. The 9-stable -> 10-release config path needs to catch fatal > > errors like this at build time. > > > > Patching GENERIC isn't a complete solution. It doesn't solve the > > 'yesterday it worked, today it's a brick' problem. > > The counter to this is that in the recent past, any suggestion to add anything > to DEFAULTS was met with "that's the wrong way". In actual fact, changes > to GENERIC happen quite often, and we often break older kernel configs from > older branches (ATA_CAM is no longer in 10 for example). I'm not sure I buy > the argument that we can never break kernel configs from older branches. When ATA_CAM went away, if one had not updated his kernel config file, then 'make buildkernel' failed. With David's change, one would build a seemingly fine kernel, and when it boots "Bad Things" (tm) can/may/will occur. Also note, yarrow is already the default (P)RNG. David is decoupling it from /dev/random. By adding it to DEFAULTS, one is only making the current relationship between /dev/random and yarrow explicit. -- Steve From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 19:20:24 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C50E0D4E for ; Thu, 8 Aug 2013 19:20:24 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8A1B92D4D for ; Thu, 8 Aug 2013 19:20:24 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id s9so2563786iec.20 for ; Thu, 08 Aug 2013 12:20:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=HhecRwGi3fow4yuYtK/G75k7dPD9ESOqfkGmjPaw1cY=; b=Rr9qIGgwyFIskIo3apbyHIv1pTXmiC1fXmo9uiLkHwE824Ir6hnubmjiwh0l3eiwXi 0zX8apK4EEGDPbUzjWEIb8rWvR9Qq7XMOjG3uoqgeoRJzz0ruIOLPTaBEj25QxWETO5u 7T6xGHXVgDiayNo+3Ev74szwEHG2zV1qn+OS/ePAy1n62UemmBGTQT/JNOBWZwnxH2Ha Q4O7DZnIHjnwRSYus/eK9HSKpn7kZLOVJ3t4V5witT3TsWgo+mUqiCU3II3ULnHeXFDD 07JLkuiu5i0Sd/Ml7wHdLZe2SEyzftafugar8PORPqAtYQVEyQ+/kIFvJcrB0eFJJBp7 JB6w== X-Gm-Message-State: ALoCoQm9qqhl9sVxtolihjncOH9Iu/kCJl5JjBHrmuDMgnI/zmAED8+5YekxsEdLdGbxmvvAnlRh X-Received: by 10.50.12.5 with SMTP id u5mr201379igb.58.1375989623290; Thu, 08 Aug 2013 12:20:23 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id kj5sm7849348igb.7.2013.08.08.12.20.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 12:20:22 -0700 (PDT) Sender: Warner Losh Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130807182858.GA79286@dragon.NUXI.org> Date: Thu, 8 Aug 2013 13:20:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <223174A5-A146-4969-A3CF-6923EF7ECCF2@bsdimp.com> References: <20130807182858.GA79286@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1085) Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:20:24 -0000 The sheer number of config files you changed says this is a bad idea, or = you are during something very wrong. Also, you bogusly changed way too many config files rather than the = underlying std.* files for the ARM port. That would, at least, solve the = 'working today, broken tomorrow' problem you're introducing with this = patch. Moving the options to the std.* files also is the proper way to = select a default RNG doohicky. What's wrong with having yarrow as the default, fallback mechanism. And = why do you have a design that seems to force one, and only one, into the = kernel? The way it is now we fail bad rather than fail to yarrow = fallback. This seems unwise. I haven't read the code in detail, but I don't see how I'd override the = CPU's random number unit with one from a plug-in board when it is = present. I'd argue that the bootverbose if statment plus #ifdef is wrong as well. There's likely other changes too, but with so many high level things = wrong with the patch, I think it would be a waste of time going through = it in more detail until those are addressed (hence my top posting rather = than doing all this inline). So while the goal may be a good one, this patch is no where near = committable as is. Warner On Aug 7, 2013, at 12:28 PM, David O'Brien wrote: > Here is a patch that improves the ability to add RNG's to the system, > even /usr/src-external as a kernel modules by creating a random(4) = plugin > infrastructure. >=20 > thoughts? >=20 > ----------%<----------%<----------%<----------%<----------%<---------- > random(4) plugin infrastructure improvement. Provides ability to = plugin > RNGs other than yarrow in a more modular fashion. >=20 > * Add random_adaptors.[ch] which is basically a store of = random_adaptor's. > random_adaptor is basically an adapter that plugs in to random(4). > random_adaptor can only be plugged in to random(4) very early in = bootup. > Unplugging random_adaptor from random(4) is not supported, and is = probably a > bad idea anyway, due to potential loss of entropy pools. > We currently have 3 random_adaptors: > + yarrow > + rdrand (ivy.c) > + nehemeiah >=20 > * Remove platform dependent logic from probe.c, and move it into > corresponding registration routines of each random_adaptor provider. > probe.c doesn't do anything other than picking a specific = random_adaptor > from a list of registered ones. >=20 > * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" = option. > The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise = yarrow. > random(4) device doesn't really depend on rijndael-*. Yarrow, = however, does. >=20 > * If the kernel doesn't have any random_adaptor adapters present then = the > creation of /dev/random is postponed until next random_adaptor is = kldload'ed. >=20 > * Fix randomdev_soft.c to refer to its own random_adaptor, instead of = a > system wide one. >=20 > Submitted by: arthurmesh@gmail.com, obrien > Obtained from: Juniper Networks > Reviewed by: obrien >=20 > ----------%<----------%<----------%<----------%<----------%<---------- >=20 > Index: UPDATING > =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 > --- UPDATING (revision 253845) > +++ UPDATING (working copy) > @@ -31,6 +31,19 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 10 > disable the most expensive debugging functionality run > "ln -s 'abort:false,junk:false' /etc/malloc.conf".) >=20 > +201308xx: > + random(4) and actual RNG implementations (aka, adaptors) have = been > + further decoupled. If you are running a custom kernel, you may > + need to explicitly enable at least one RNG adaptor in your = kernel > + config. For example, to use Yarrow, add "options YARROW_RNG" to > + your kernel config. For hardware backed RNGs, use either > + "RDRAND_RNG" or "PADLOCK_RNG" options. > + If you use random.ko via 'random_load=3D"YES"' in = /boot/loader.conf > + instead of "device random", you will need to change that to > + 'yarrow_rng_load=3D"YES"', 'rdrand_rng_load=3D"YES"', or > + 'padlock_rng_load=3D"YES"'. random.ko will be loaded = automatically > + as a dependency module. > + > 20130726: > Behavior of devfs rules path matching has been changed. > Pattern is now always matched against fully qualified devfs > Index: share/man/man4/random.4 > =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 > --- share/man/man4/random.4 (revision 253845) > +++ share/man/man4/random.4 (working copy) > @@ -23,7 +23,7 @@ > .\" > .\" $FreeBSD$ > .\" > -.Dd September 7, 2012 > +.Dd August xx, 2013 > .Dt RANDOM 4 > .Os > .Sh NAME > @@ -43,6 +43,13 @@ The device will probe for > certain hardware entropy sources, > and use these in preference to the fallback, > which is a generator implemented in software. > +If the kernel environment MIB's > +.Va hw.nehemiah_rng_enable > +or > +.Va hw.ivy_rng_enable > +are set to > +.Dq Li 0 , > +the associated hardware entropy source will be ignored. > .Pp > If the device is using > the software generator, > @@ -74,6 +81,7 @@ device, use the command line: > .Pp > which results in something like: > .Bd -literal -offset indent > +kern.random.adaptors: yarrow > kern.random.sys.seeded: 1 > kern.random.sys.harvest.ethernet: 1 > kern.random.sys.harvest.point_to_point: 1 > @@ -89,7 +97,9 @@ kern.random.yarrow.slowoverthresh: 2 > (These would not be seen if a > hardware generator is present.) > .Pp > -All settings are read/write. > +Other than > +.Dl kern.random.adaptors > +all settings are read/write. > .Pp > The > .Va kern.random.sys.seeded > Index: sys/amd64/conf/GENERIC > =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 > --- sys/amd64/conf/GENERIC (revision 253845) > +++ sys/amd64/conf/GENERIC (working copy) > @@ -295,6 +295,7 @@ device loop # Network = loopback > device random # Entropy device > options PADLOCK_RNG # VIA Padlock RNG > options RDRAND_RNG # Intel Bull Mountain RNG > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > device vlan # 802.1Q VLAN support > device tun # Packet tunnel. > Index: sys/arm/conf/AC100 > =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 > --- sys/arm/conf/AC100 (revision 253845) > +++ sys/arm/conf/AC100 (working copy) > @@ -61,6 +61,7 @@ options MUTEX_DEBUG >=20 > # Pseudo devices > device random > +options YARROW_RNG # Yarrow software RNG > device pty > device loop > device md > Index: sys/arm/conf/ARMADAXP > =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 > --- sys/arm/conf/ARMADAXP (revision 253845) > +++ sys/arm/conf/ARMADAXP (working copy) > @@ -61,6 +61,7 @@ options KDB_TRACE >=20 > # Pseudo devices > device random > +options YARROW_RNG # Yarrow software RNG > device pty > device loop > device md > Index: sys/arm/conf/ARNDALE > =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 > --- sys/arm/conf/ARNDALE (revision 253845) > +++ sys/arm/conf/ARNDALE (working copy) > @@ -88,6 +88,7 @@ options ROOTDEVNAME=3D\"ufs:/dev/da0\" >=20 > device loop > device random > +options YARROW_RNG # Yarrow software RNG > device pty > device md > device gpio > Index: sys/arm/conf/ATMEL > =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 > --- sys/arm/conf/ATMEL (revision 253845) > +++ sys/arm/conf/ATMEL (working copy) > @@ -134,6 +134,7 @@ device geom_map # GEOM partition = mappin > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > device vlan # 802.1Q VLAN support > device tun # Packet tunnel. > Index: sys/arm/conf/AVILA > =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 > --- sys/arm/conf/AVILA (revision 253845) > +++ sys/arm/conf/AVILA (working copy) > @@ -107,6 +107,7 @@ device if_bridge >=20 > device md > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG >=20 > # Wireless NIC cards > device wlan # 802.11 support > Index: sys/arm/conf/BEAGLEBONE > =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 > --- sys/arm/conf/BEAGLEBONE (revision 253845) > +++ sys/arm/conf/BEAGLEBONE (working copy) > @@ -90,6 +90,7 @@ device pty > device snp > device md > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG >=20 > # I2C support > device iicbus > Index: sys/arm/conf/BWCT > =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 > --- sys/arm/conf/BWCT (revision 253845) > +++ sys/arm/conf/BWCT (working copy) > @@ -68,6 +68,7 @@ options NO_FFS_SNAPSHOT > options NO_SWAPPING > device loop > device random > +options YARROW_RNG # Yarrow software RNG > device ether > device vlan > device uart > Index: sys/arm/conf/CAMBRIA > =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 > --- sys/arm/conf/CAMBRIA (revision 253845) > +++ sys/arm/conf/CAMBRIA (working copy) > @@ -110,6 +110,7 @@ device if_bridge >=20 > device md > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG >=20 > # Wireless NIC cards > device wlan # 802.11 support > Index: sys/arm/conf/CNS11XXNAS > =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 > --- sys/arm/conf/CNS11XXNAS (revision 253845) > +++ sys/arm/conf/CNS11XXNAS (working copy) > @@ -102,6 +102,7 @@ device loop >=20 > device md > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG >=20 > #options ARM_USE_SMALL_ALLOC >=20 > Index: sys/arm/conf/CRB > =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 > --- sys/arm/conf/CRB (revision 253845) > +++ sys/arm/conf/CRB (working copy) > @@ -105,6 +105,7 @@ options DDB #Enable the = kernel debugg > options XSCALE_CACHE_READ_WRITE_ALLOCATE > device md > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG >=20 > device iopwdog > options ARM_USE_SMALL_ALLOC > Index: sys/arm/conf/CUBIEBOARD > =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 > --- sys/arm/conf/CUBIEBOARD (revision 253845) > +++ sys/arm/conf/CUBIEBOARD (working copy) > @@ -92,6 +92,7 @@ device pty > device snp > device md > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG >=20 > # I2C support > #device iicbus > @@ -130,4 +131,3 @@ device miibus > options FDT > options FDT_DTB_STATIC > makeoptions FDT_DTS_FILE=3Dcubieboard.dts > - > Index: sys/arm/conf/DB-78XXX > =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 > --- sys/arm/conf/DB-78XXX (revision 253845) > +++ sys/arm/conf/DB-78XXX (working copy) > @@ -55,6 +55,7 @@ device pci > device loop > device md > device random > +options YARROW_RNG # Yarrow software RNG >=20 > # Serial ports > device uart > Index: sys/arm/conf/DB-88F5XXX > =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 > --- sys/arm/conf/DB-88F5XXX (revision 253845) > +++ sys/arm/conf/DB-88F5XXX (working copy) > @@ -54,6 +54,7 @@ device pci > device md > device loop > device random > +options YARROW_RNG # Yarrow software RNG >=20 > # Serial ports > device uart > Index: sys/arm/conf/DB-88F6XXX > =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 > --- sys/arm/conf/DB-88F6XXX (revision 253845) > +++ sys/arm/conf/DB-88F6XXX (working copy) > @@ -55,6 +55,7 @@ device pci > device loop > device md > device random > +options YARROW_RNG # Yarrow software RNG >=20 > # Serial ports > device uart > Index: sys/arm/conf/DOCKSTAR > =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 > --- sys/arm/conf/DOCKSTAR (revision 253845) > +++ sys/arm/conf/DOCKSTAR (working copy) > @@ -46,6 +46,7 @@ options KDB > # Pseudo devices > device md > device random > +options YARROW_RNG # Yarrow software RNG > device loop >=20 > # Serial ports > Index: sys/arm/conf/DREAMPLUG-1001 > =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 > --- sys/arm/conf/DREAMPLUG-1001 (revision 253845) > +++ sys/arm/conf/DREAMPLUG-1001 (working copy) > @@ -62,6 +62,7 @@ device loop #Network = loopback > device md #Memory/malloc disk > device pty #BSD-style compatibility = pseudo ttys > device random #Entropy device > +options YARROW_RNG # Yarrow software RNG > device tun #Packet tunnel. > device ether #Required for all = ethernet devices > device vlan #802.1Q VLAN support > Index: sys/arm/conf/EA3250 > =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 > --- sys/arm/conf/EA3250 (revision 253845) > +++ sys/arm/conf/EA3250 (working copy) > @@ -54,6 +54,7 @@ device loop > device md > device pty > device random > +options YARROW_RNG # Yarrow software RNG >=20 > # Serial ports > device uart > Index: sys/arm/conf/EB9200 > =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 > --- sys/arm/conf/EB9200 (revision 253845) > +++ sys/arm/conf/EB9200 (working copy) > @@ -60,6 +60,7 @@ options SX_NOINLINE > options NO_FFS_SNAPSHOT > options NO_SWAPPING > device random > +options YARROW_RNG # Yarrow software RNG > device loop > device ether > device uart > Index: sys/arm/conf/EFIKA_MX > =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 > --- sys/arm/conf/EFIKA_MX (revision 253845) > +++ sys/arm/conf/EFIKA_MX (working copy) > @@ -96,6 +96,7 @@ device bpf # Berkeley = packet filter > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > #device vlan # 802.1Q VLAN support > #device tun # Packet tunnel. > Index: sys/arm/conf/EP80219 > =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 > --- sys/arm/conf/EP80219 (revision 253845) > +++ sys/arm/conf/EP80219 (working copy) > @@ -101,6 +101,7 @@ options DDB #Enable the = kernel debugg > options XSCALE_CACHE_READ_WRITE_ALLOCATE > device md > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG >=20 > options ARM_USE_SMALL_ALLOC > # Floppy drives > Index: sys/arm/conf/ETHERNUT5 > =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 > --- sys/arm/conf/ETHERNUT5 (revision 253845) > +++ sys/arm/conf/ETHERNUT5 (working copy) > @@ -126,6 +126,7 @@ device geom_map # GEOM partition = mappin > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > #device vlan # 802.1Q VLAN support > #device tun # Packet tunnel. > Index: sys/arm/conf/GUMSTIX > =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 > --- sys/arm/conf/GUMSTIX (revision 253845) > +++ sys/arm/conf/GUMSTIX (working copy) > @@ -88,3 +88,4 @@ options DDB #Enable the = kernel debugg >=20 > device md > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > Index: sys/arm/conf/HL200 > =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 > --- sys/arm/conf/HL200 (revision 253845) > +++ sys/arm/conf/HL200 (working copy) > @@ -65,6 +65,7 @@ options RWLOCK_NOINLINE > options NO_FFS_SNAPSHOT > options NO_SWAPPING > device random > +options YARROW_RNG # Yarrow software RNG > device loop > device ether > device uart > Index: sys/arm/conf/HL201 > =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 > --- sys/arm/conf/HL201 (revision 253845) > +++ sys/arm/conf/HL201 (working copy) > @@ -67,6 +67,7 @@ options RWLOCK_NOINLINE > options NO_FFS_SNAPSHOT > options NO_SWAPPING > device random > +options YARROW_RNG # Yarrow software RNG > device loop > device ether > device uart > @@ -129,4 +130,3 @@ device pass # Passthrough = device (dire > #device wlan_tkip # 802.11 TKIP support > #device wlan_amrr # AMRR transmit rate control = algorithm > options ROOTDEVNAME=3D\"ufs:da0s1a\" > - > Index: sys/arm/conf/IQ31244 > =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 > --- sys/arm/conf/IQ31244 (revision 253845) > +++ sys/arm/conf/IQ31244 (working copy) > @@ -106,6 +106,7 @@ options DDB #Enable the = kernel debugg > options XSCALE_CACHE_READ_WRITE_ALLOCATE > device md > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG >=20 > options ARM_USE_SMALL_ALLOC > # Floppy drives > Index: sys/arm/conf/KB920X > =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 > --- sys/arm/conf/KB920X (revision 253845) > +++ sys/arm/conf/KB920X (working copy) > @@ -66,6 +66,7 @@ options SX_NOINLINE > options NO_FFS_SNAPSHOT > options NO_SWAPPING > device random > +options YARROW_RNG # Yarrow software RNG > device loop > device ether > device uart > Index: sys/arm/conf/LN2410SBC > =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 > --- sys/arm/conf/LN2410SBC (revision 253845) > +++ sys/arm/conf/LN2410SBC (working copy) > @@ -62,6 +62,7 @@ options SX_NOINLINE > options NO_FFS_SNAPSHOT > options NO_SWAPPING > device random > +options YARROW_RNG # Yarrow software RNG >=20 > device loop > device ether > @@ -83,4 +84,3 @@ device ohci > device umass > device scbus # SCSI bus (required for da) > device da # Direct Access (disks) > - > Index: sys/arm/conf/NSLU > =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 > --- sys/arm/conf/NSLU (revision 253845) > +++ sys/arm/conf/NSLU (working copy) > @@ -105,6 +105,7 @@ device loop >=20 > device md > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG >=20 > #options ARM_USE_SMALL_ALLOC >=20 > Index: sys/arm/conf/PANDABOARD > =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 > --- sys/arm/conf/PANDABOARD (revision 253845) > +++ sys/arm/conf/PANDABOARD (working copy) > @@ -110,6 +110,7 @@ device md > #options MD_ROOT_SIZE=3D7560 >=20 > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG >=20 > # USB support > device usb > Index: sys/arm/conf/QILA9G20 > =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 > --- sys/arm/conf/QILA9G20 (revision 253845) > +++ sys/arm/conf/QILA9G20 (working copy) > @@ -77,6 +77,7 @@ options NO_SWAPPING > #options DIAGNOSTIC >=20 > device random > +options YARROW_RNG # Yarrow software RNG > device loop > device bpf > device ether > Index: sys/arm/conf/RPI-B > =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 > --- sys/arm/conf/RPI-B (revision 253845) > +++ sys/arm/conf/RPI-B (working copy) > @@ -86,6 +86,7 @@ options INVARIANT_SUPPORT #Extra sanity >=20 > device md > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG >=20 > # USB support > device usb > Index: sys/arm/conf/SAM9260EK > =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 > --- sys/arm/conf/SAM9260EK (revision 253845) > +++ sys/arm/conf/SAM9260EK (working copy) > @@ -134,6 +134,7 @@ device mmcsd # MMC/SD memory = card > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > #device vlan # 802.1Q VLAN support > #device tun # Packet tunnel. > Index: sys/arm/conf/SAM9G20EK > =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 > --- sys/arm/conf/SAM9G20EK (revision 253845) > +++ sys/arm/conf/SAM9G20EK (working copy) > @@ -76,6 +76,7 @@ options NO_SWAPPING > #options DIAGNOSTIC >=20 > device random > +options YARROW_RNG # Yarrow software RNG > device loop > device bpf > device ether > Index: sys/arm/conf/SAM9X25EK > =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 > --- sys/arm/conf/SAM9X25EK (revision 253845) > +++ sys/arm/conf/SAM9X25EK (working copy) > @@ -77,6 +77,7 @@ options NO_SWAPPING > #options DIAGNOSTIC >=20 > device random > +options YARROW_RNG # Yarrow software RNG > device pty > device loop > device bpf > @@ -150,4 +151,3 @@ device miibus > #device wlan_ccmp # 802.11 CCMP support > #device wlan_tkip # 802.11 TKIP support > #device wlan_amrr # AMRR transmit rate control = algorithm > - > Index: sys/arm/conf/SHEEVAPLUG > =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 > --- sys/arm/conf/SHEEVAPLUG (revision 253845) > +++ sys/arm/conf/SHEEVAPLUG (working copy) > @@ -45,6 +45,7 @@ options KDB >=20 > # Pseudo devices > device random > +options YARROW_RNG # Yarrow software RNG > device loop >=20 > # Serial ports > Index: sys/arm/conf/SN9G45 > =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 > --- sys/arm/conf/SN9G45 (revision 253845) > +++ sys/arm/conf/SN9G45 (working copy) > @@ -76,6 +76,7 @@ options NO_SWAPPING > #options DIAGNOSTIC >=20 > device random > +options YARROW_RNG # Yarrow software RNG > device loop > device bpf > device ether > Index: sys/arm/conf/TS7800 > =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 > --- sys/arm/conf/TS7800 (revision 253845) > +++ sys/arm/conf/TS7800 (working copy) > @@ -48,6 +48,7 @@ device pci > device md > device loop > device random > +options YARROW_RNG # Yarrow software RNG >=20 > # Serial ports > device uart > Index: sys/arm/conf/VERSATILEPB > =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 > --- sys/arm/conf/VERSATILEPB (revision 253845) > +++ sys/arm/conf/VERSATILEPB (working copy) > @@ -94,6 +94,7 @@ options INVARIANT_SUPPORT #Extra sanity >=20 > device md > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG >=20 > # Flattened Device Tree > options FDT > Index: sys/arm/conf/ZEDBOARD > =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 > --- sys/arm/conf/ZEDBOARD (revision 253845) > +++ sys/arm/conf/ZEDBOARD (working copy) > @@ -66,6 +66,7 @@ options KDB >=20 > device loop > device random > +options YARROW_RNG # Yarrow software RNG > device ether > device if_cgem # Zynq-7000 gig ethernet = device > device mii > Index: sys/conf/NOTES > =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 > --- sys/conf/NOTES (revision 253845) > +++ sys/conf/NOTES (working copy) > @@ -1132,6 +1132,9 @@ options VFS_AIO > # Cryptographically secure random number generator; /dev/random > device random >=20 > +# Yarrow software RNG adapter for random > +options YARROW_RNG > + > # The system memory devices; /dev/mem, /dev/kmem > device mem >=20 > Index: sys/conf/files > =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 > --- sys/conf/files (revision 253845) > +++ sys/conf/files (working copy) > @@ -540,8 +540,8 @@ crypto/des/des_ecb.c optional crypto = |=20 > crypto/des/des_setkey.c optional crypto | ipsec | netsmb > crypto/rc4/rc4.c optional netgraph_mppc_encryption | = kgssapi > crypto/rijndael/rijndael-alg-fst.c optional crypto | geom_bde | \ > - ipsec | random | wlan_ccmp > -crypto/rijndael/rijndael-api-fst.c optional geom_bde | random > + ipsec | yarrow_rng | wlan_ccmp > +crypto/rijndael/rijndael-api-fst.c optional geom_bde | yarrow_rng > crypto/rijndael/rijndael-api.c optional crypto | ipsec | = wlan_ccmp > crypto/sha1.c optional carp | crypto | ipsec | \ > netgraph_mppc_encryption | sctp > @@ -2030,11 +2030,12 @@ rt2860.fw optional = rt2860fw | ralfw \ > no-obj no-implicit-rule = \ > clean "rt2860.fw" > dev/random/harvest.c standard > -dev/random/hash.c optional random > +dev/random/hash.c optional yarrow_rng > dev/random/probe.c optional random > +dev/random/random_adaptors.c standard > dev/random/randomdev.c optional random > -dev/random/randomdev_soft.c optional random > -dev/random/yarrow.c optional random > +dev/random/randomdev_soft.c optional yarrow_rng > +dev/random/yarrow.c optional yarrow_rng > dev/rc/rc.c optional rc > dev/re/if_re.c optional re > dev/rndtest/rndtest.c optional rndtest > Index: sys/conf/options > =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 > --- sys/conf/options (revision 253845) > +++ sys/conf/options (working copy) > @@ -905,3 +905,6 @@ RACCT opt_global.h >=20 > # Resource Limits > RCTL opt_global.h > + > +# Software random number generators for random(4) > +YARROW_RNG opt_dontuse.h > Index: sys/dev/random/ivy.c > =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 > --- sys/dev/random/ivy.c (revision 253846) > +++ sys/dev/random/ivy.c (working copy) > @@ -28,16 +28,19 @@ > #include > __FBSDID("$FreeBSD$"); >=20 > -#include "opt_cpu.h" > - > -#ifdef RDRAND_RNG > - > #include > #include > +#include > #include > +#include > #include > #include > #include > + > +#include > +#include > + > +#include > #include >=20 > #define RETRY_COUNT 10 > @@ -46,7 +49,7 @@ static void random_ivy_init(void); > static void random_ivy_deinit(void); > static int random_ivy_read(void *, int); >=20 > -struct random_systat random_ivy =3D { > +struct random_adaptor random_ivy =3D { > .ident =3D "Hardware, Intel IvyBridge+ RNG", > .init =3D random_ivy_init, > .deinit =3D random_ivy_deinit, > @@ -114,4 +117,32 @@ random_ivy_read(void *buf, int c) > return (c - count); > } >=20 > +static int > +rdrand_modevent(module_t mod, int type, void *unused) > +{ > + > + switch (type) { > + case MOD_LOAD: > + if (cpu_feature2 & CPUID2_RDRAND) { > + random_adaptor_register("rdrand", &random_ivy); > + EVENTHANDLER_INVOKE(random_adaptor_attach, = &random_ivy); > + return (0); > + } else { > +#ifndef KLD_MODULE > + if (bootverbose) > +#endif > + printf( > + "%s: RDRAND feature is not present on this = CPU\n", > + random_ivy.ident); > +#ifdef KLD_MODULE > + return (ENXIO); > +#else > + return (0); > #endif > + } > + } > + > + return (EINVAL); > +} > + > +RANDOM_ADAPTOR_MODULE(random_rdrand, rdrand_modevent, 1); > Index: sys/dev/random/nehemiah.c > =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 > --- sys/dev/random/nehemiah.c (revision 253846) > +++ sys/dev/random/nehemiah.c (working copy) > @@ -28,19 +28,20 @@ > #include > __FBSDID("$FreeBSD$"); >=20 > -#include "opt_cpu.h" > - > -#ifdef PADLOCK_RNG > - > #include > #include > #include > #include > +#include > #include > #include > +#include >=20 > #include > +#include > +#include >=20 > +#include > #include >=20 > #define RANDOM_BLOCK_SIZE 256 > @@ -50,7 +51,7 @@ static void random_nehemiah_init(void); > static void random_nehemiah_deinit(void); > static int random_nehemiah_read(void *, int); >=20 > -struct random_systat random_nehemiah =3D { > +struct random_adaptor random_nehemiah =3D { > .ident =3D "Hardware, VIA Nehemiah", > .init =3D random_nehemiah_init, > .deinit =3D random_nehemiah_deinit, > @@ -208,4 +209,33 @@ random_nehemiah_read(void *buf, int c) > return (c); > } >=20 > +static int > +nehemiah_modevent(module_t mod, int type, void *unused) > +{ > + > + switch (type) { > + case MOD_LOAD: > + if (via_feature_rng & VIA_HAS_RNG) { > + random_adaptor_register("nehemiah", = &random_nehemiah); > + EVENTHANDLER_INVOKE(random_adaptor_attach, > + &random_nehemiah); > + return (0); > + } else { > +#ifndef KLD_MODULE > + if (bootverbose) > +#endif > + printf( > + "%s: VIA RNG feature is not present on this = CPU\n", > + random_nehemiah.ident); > +#ifdef KLD_MODULE > + return (ENXIO); > +#else > + return (0); > #endif > + } > + } > + > + return (EINVAL); > +} > + > +RANDOM_ADAPTOR_MODULE(nehemiah, nehemiah_modevent, 1); > Index: sys/dev/random/probe.c > =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 > --- sys/dev/random/probe.c (revision 253846) > +++ sys/dev/random/probe.c (working copy) > @@ -28,66 +28,35 @@ > #include > __FBSDID("$FreeBSD$"); >=20 > -#if defined(__amd64__) || (defined(__i386__) && !defined(PC98)) > +#if defined(__amd64__) || defined(__i386__) > #include "opt_cpu.h" > #endif >=20 > -#include > #include > #include > #include > -#include > -#include > #include > -#include > - > -#if defined(__amd64__) || (defined(__i386__) && !defined(PC98)) > -#include > -#include > -#include > -#include > -#endif >=20 > +#include > #include > -#include > - > -#if defined(__amd64__) || (defined(__i386__) && !defined(PC98)) > -#ifdef PADLOCK_RNG > -extern struct random_systat random_nehemiah; > -#endif > -#ifdef RDRAND_RNG > -extern struct random_systat random_ivy; > -#endif > -#endif >=20 > void > -random_ident_hardware(struct random_systat **systat) > +random_ident_hardware(struct random_adaptor **adaptor) > { > + struct random_adaptor *tmp; > + int enable; >=20 > - /* Set default to software */ > - *systat =3D &random_yarrow; > + /* Set default to software (yarrow) */ > + *adaptor =3D random_adaptor_get("yarrow"); >=20 > /* Then go looking for hardware */ > -#if defined(__amd64__) || (defined(__i386__) && !defined(PC98)) > -#ifdef PADLOCK_RNG > - if (via_feature_rng & VIA_HAS_RNG) { > - int enable; > - > - enable =3D 1; > - TUNABLE_INT_FETCH("hw.nehemiah_rng_enable", &enable); > - if (enable) > - *systat =3D &random_nehemiah; > - } > -#endif > -#ifdef RDRAND_RNG > - if (cpu_feature2 & CPUID2_RDRAND) { > - int enable; > + enable =3D 1; > + TUNABLE_INT_FETCH("hw.nehemiah_rng_enable", &enable); > + if (enable && (tmp =3D random_adaptor_get("nehemiah"))) > + *adaptor =3D tmp; >=20 > - enable =3D 1; > - TUNABLE_INT_FETCH("hw.ivy_rng_enable", &enable); > - if (enable) > - *systat =3D &random_ivy; > - } > -#endif > -#endif > + enable =3D 1; > + TUNABLE_INT_FETCH("hw.ivy_rng_enable", &enable); > + if (enable && (tmp =3D random_adaptor_get("rdrand"))) > + *adaptor =3D tmp; > } > Index: sys/dev/random/random_adaptors.c > =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 > --- sys/dev/random/random_adaptors.c (revision 0) > +++ sys/dev/random/random_adaptors.c (working copy) > @@ -0,0 +1,137 @@ > +/*- > + * Copyright (c) 2013 Arthur Mesh > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + * notice, this list of conditions and the following disclaimer > + * in this position and unchanged. > + * 2. Redistributions in binary form must reproduce the above = copyright > + * notice, this list of conditions and the following disclaimer in = the > + * documentation and/or other materials provided with the = distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS = OR > + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED = WARRANTIES > + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE = DISCLAIMED. > + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, > + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES = (INCLUDING, BUT > + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS = OF USE, > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON = ANY > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR = TORT > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE = USE OF > + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > + * > + * $FreeBSD$ > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > + > +LIST_HEAD(adaptors_head, random_adaptors); > +static struct adaptors_head adaptors =3D = LIST_HEAD_INITIALIZER(adaptors); > +static struct sx adaptors_lock; /* need a sleepable lock */ > + > +/* List for the dynamic sysctls */ > +static struct sysctl_ctx_list random_clist; > + > +MALLOC_DEFINE(M_RANDOM_ADAPTORS, "random_adaptors", "Random adaptors = buffers"); > + > +int > +random_adaptor_register(const char *name, struct random_adaptor *rsp) > +{ > + struct random_adaptors *rpp; > + > + KASSERT(name !=3D NULL && rsp !=3D NULL, ("invalid input to %s", = __func__)); > + > + rpp =3D malloc(sizeof(struct random_adaptors), = M_RANDOM_ADAPTORS, M_WAITOK); > + rpp->name =3D name; > + rpp->rsp =3D rsp; > + > + sx_xlock(&adaptors_lock); > + LIST_INSERT_HEAD(&adaptors, rpp, entries); > + sx_xunlock(&adaptors_lock); > + > + return (0); > +} > + > +struct random_adaptor * > +random_adaptor_get(const char *name) > +{ > + struct random_adaptors *rpp; > + struct random_adaptor *rsp; > + > + rsp =3D NULL; > + > + sx_slock(&adaptors_lock); > + > + LIST_FOREACH(rpp, &adaptors, entries) > + if (strcmp(rpp->name, name) =3D=3D 0) > + rsp =3D rpp->rsp; > + > + sx_sunlock(&adaptors_lock); > + > + return (rsp); > +} > + > +static void > +random_adaptors_deinit(void *unused) > +{ > + > + sx_destroy(&adaptors_lock); > + sysctl_ctx_free(&random_clist); > +} > + > +static int > +random_sysctl_adaptors_handler(SYSCTL_HANDLER_ARGS) > +{ > + struct random_adaptors *rpp; > + int error; > + > + error =3D 0; > + > + sx_slock(&adaptors_lock); > + > + if (LIST_EMPTY(&adaptors)) > + error =3D SYSCTL_OUT(req, "", strlen("")); > + > + LIST_FOREACH(rpp, &adaptors, entries) { > + if (0 !=3D SYSCTL_OUT(req, rpp->name, = strlen(rpp->name))) > + break; > + } > + > + sx_sunlock(&adaptors_lock); > + > + return (error); > +} > + > +static void > +random_adaptors_init(void *unused) > +{ > + > + SYSCTL_PROC(_kern_random, OID_AUTO, adaptors, > + CTLTYPE_STRING | CTLFLAG_RD | CTLFLAG_MPSAFE, > + NULL, 0, random_sysctl_adaptors_handler, "", > + "Random Number Generator adaptors"); > + > + sx_init(&adaptors_lock, "random_adaptors"); > +} > + > +SYSCTL_NODE(_kern, OID_AUTO, random, CTLFLAG_RW, 0, "Random Number = Generator"); > + > +SYSINIT(random_adaptors, SI_SUB_DRIVERS, SI_ORDER_FIRST, = random_adaptors_init, > + NULL); > +SYSUNINIT(random_adaptors, SI_SUB_DRIVERS, SI_ORDER_FIRST, > + random_adaptors_deinit, NULL); >=20 > Property changes on: sys/dev/random/random_adaptors.c > ___________________________________________________________________ > Added: svn:eol-style > ## -0,0 +1 ## > +native > \ No newline at end of property > Added: svn:mime-type > ## -0,0 +1 ## > +text/plain > \ No newline at end of property > Added: svn:keywords > ## -0,0 +1 ## > +FreeBSD=3D%H > \ No newline at end of property > Index: sys/dev/random/random_adaptors.h > =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 > --- sys/dev/random/random_adaptors.h (revision 0) > +++ sys/dev/random/random_adaptors.h (working copy) > @@ -0,0 +1,66 @@ > +/*- > + * Copyright (c) 2013 Arthur Mesh > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > + * modification, are permitted provided that the following conditions > + * are met: > + * 1. Redistributions of source code must retain the above copyright > + * notice, this list of conditions and the following disclaimer > + * in this position and unchanged. > + * 2. Redistributions in binary form must reproduce the above = copyright > + * notice, this list of conditions and the following disclaimer in = the > + * documentation and/or other materials provided with the = distribution. > + * > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS = OR > + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED = WARRANTIES > + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE = DISCLAIMED. > + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, > + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES = (INCLUDING, BUT > + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS = OF USE, > + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON = ANY > + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR = TORT > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE = USE OF > + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > + * > + * $FreeBSD$ > + */ > + > +#ifndef __RANDOM_ADAPTORS_H__ > +#define __RANDOM_ADAPTORS_H__ > + > +#include > + > +struct random_adaptors { > + LIST_ENTRY(random_adaptors) entries; /* list of providesr */ > + const char *name; /* name of random = adaptor */ > + struct random_adaptor *rsp; > +}; > + > +struct random_adaptor *random_adaptor_get(const char *); > +int random_adaptor_register(const char *, struct random_adaptor *); > + > +/* > + * random_adaptor's should be registered prior to > + * random module (SI_SUB_DRIVERS/SI_ORDER_MIDDLE) > + */ > +#define RANDOM_ADAPTOR_MODULE(name, modevent, ver) \ > + static moduledata_t name##_mod =3D { = \ > + #name, \ > + modevent, \ > + 0 \ > + }; = \ > + DECLARE_MODULE(name, name##_mod, SI_SUB_DRIVERS, \ > + SI_ORDER_SECOND); \ > + MODULE_VERSION(name, ver); = \ > + MODULE_DEPEND(name, random, 1, 1, 1); > + > +typedef void (*random_adaptor_attach_hook)(void *, struct = random_adaptor *); > +EVENTHANDLER_DECLARE(random_adaptor_attach, = random_adaptor_attach_hook); > + > +/* kern.random sysctls */ > +#ifdef SYSCTL_DECL /* from sysctl.h */ > +SYSCTL_DECL(_kern_random); > +#endif /* SYSCTL_DECL */ > + > +#endif /* __RANDOM_ADAPTORS_H__ */ >=20 > Property changes on: sys/dev/random/random_adaptors.h > ___________________________________________________________________ > Added: svn:mime-type > ## -0,0 +1 ## > +text/plain > \ No newline at end of property > Added: svn:keywords > ## -0,0 +1 ## > +FreeBSD=3D%H > \ No newline at end of property > Added: svn:eol-style > ## -0,0 +1 ## > +native > \ No newline at end of property > Index: sys/dev/random/randomdev.c > =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 > --- sys/dev/random/randomdev.c (revision 253846) > +++ sys/dev/random/randomdev.c (working copy) > @@ -70,12 +70,15 @@ static struct cdevsw random_cdevsw =3D { > .d_name =3D "random", > }; >=20 > -struct random_systat *random_systat; > +static struct random_adaptor *random_adaptor; > +static eventhandler_tag attach_tag; > +static int random_inited; > + >=20 > /* For use with make_dev(9)/destroy_dev(9). */ > static struct cdev *random_dev; >=20 > -/* Used to fake out unused random calls in random_systat */ > +/* Used to fake out unused random calls in random_adaptor */ > void > random_null_func(void) > { > @@ -88,8 +91,8 @@ random_close(struct cdev *dev __unused,=20 > { > if ((flags & FWRITE) && (priv_check(td, PRIV_RANDOM_RESEED) =3D=3D= 0) > && (securelevel_gt(td->td_ucred, 0) =3D=3D 0)) { > - (*random_systat->reseed)(); > - random_systat->seeded =3D 1; > + (*random_adaptor->reseed)(); > + random_adaptor->seeded =3D 1; > arc4rand(NULL, 0, 1); /* Reseed arc4random as well. */ > } >=20 > @@ -104,8 +107,8 @@ random_read(struct cdev *dev __unused, s > void *random_buf; >=20 > /* Blocking logic */ > - if (!random_systat->seeded) > - error =3D (*random_systat->block)(flag); > + if (!random_adaptor->seeded) > + error =3D (*random_adaptor->block)(flag); >=20 > /* The actual read */ > if (!error) { > @@ -114,7 +117,7 @@ random_read(struct cdev *dev __unused, s >=20 > while (uio->uio_resid > 0 && !error) { > c =3D MIN(uio->uio_resid, PAGE_SIZE); > - c =3D (*random_systat->read)(random_buf, c); > + c =3D (*random_adaptor->read)(random_buf, c); > error =3D uiomove(random_buf, c, uio); > } >=20 > @@ -139,7 +142,7 @@ random_write(struct cdev *dev __unused,=20 > error =3D uiomove(random_buf, c, uio); > if (error) > break; > - (*random_systat->write)(random_buf, c); > + (*random_adaptor->write)(random_buf, c); > } >=20 > free(random_buf, M_TEMP); > @@ -172,14 +175,37 @@ random_poll(struct cdev *dev __unused, i > int revents =3D 0; >=20 > if (events & (POLLIN | POLLRDNORM)) { > - if (random_systat->seeded) > + if (random_adaptor->seeded) > revents =3D events & (POLLIN | POLLRDNORM); > else > - revents =3D (*random_systat->poll) (events,td); > + revents =3D (*random_adaptor->poll) (events,td); > } > return (revents); > } >=20 > +static void > +random_initialize(void *p, struct random_adaptor *s) > +{ > + if (random_inited) { > + printf("random: <%s> already initialized\n", > + random_adaptor->ident); > + return; > + } > + > + random_adaptor =3D s; > + > + (s->init)(); > + > + printf("random: <%s> initialized\n", s->ident); > + > + random_dev =3D make_dev_credf(MAKEDEV_ETERNAL_KLD, = &random_cdevsw, > + RANDOM_MINOR, NULL, UID_ROOT, GID_WHEEL, 0666, "random"); > + make_dev_alias(random_dev, "urandom"); /* XXX Deprecated */ > + > + /* mark random(4) as initialized, to avoid being called again */ > + random_inited =3D 1; > +} > + > /* ARGSUSED */ > static int > random_modevent(module_t mod __unused, int type, void *data __unused) > @@ -188,23 +214,29 @@ random_modevent(module_t mod __unused, i >=20 > switch (type) { > case MOD_LOAD: > - random_ident_hardware(&random_systat); > - (*random_systat->init)(); > - > - if (bootverbose) > - printf("random: \n", > - random_systat->ident); > + random_ident_hardware(&random_adaptor); >=20 > - random_dev =3D make_dev_credf(MAKEDEV_ETERNAL_KLD, = &random_cdevsw, > - RANDOM_MINOR, NULL, UID_ROOT, GID_WHEEL, 0666, = "random"); > - make_dev_alias(random_dev, "urandom"); /* XXX = Deprecated */ > + if (random_adaptor =3D=3D NULL) { > + printf( > + "random: No random adaptor attached, postponing = initialization\n"); > + attach_tag =3D = EVENTHANDLER_REGISTER(random_adaptor_attach, > + random_initialize, NULL, = EVENTHANDLER_PRI_ANY); > + } else { > + random_initialize(NULL, random_adaptor); > + } >=20 > break; >=20 > case MOD_UNLOAD: > - (*random_systat->deinit)(); > - > - destroy_dev(random_dev); > + if (random_adaptor !=3D NULL) { > + (*random_adaptor->deinit)(); > + destroy_dev(random_dev); > + } > + /* Unregister the event handler */ > + if (attach_tag !=3D NULL) { > + EVENTHANDLER_DEREGISTER(random_adaptor_attach, > + attach_tag); > + } >=20 > break; >=20 > Index: sys/dev/random/randomdev.h > =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 > --- sys/dev/random/randomdev.h (revision 253846) > +++ sys/dev/random/randomdev.h (working copy) > @@ -38,7 +38,7 @@ typedef void random_write_func_t(void *, > typedef int random_poll_func_t(int, struct thread *); > typedef void random_reseed_func_t(void); >=20 > -struct random_systat { > +struct random_adaptor { > struct selinfo rsel; > const char *ident; > int seeded; > @@ -51,7 +51,5 @@ struct random_systat { > random_reseed_func_t *reseed; > }; >=20 > -extern struct random_systat *random_systat; > - > -extern void random_ident_hardware(struct random_systat **); > +extern void random_ident_hardware(struct random_adaptor **); > extern void random_null_func(void); > Index: sys/dev/random/randomdev_soft.c > =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 > --- sys/dev/random/randomdev_soft.c (revision 253846) > +++ sys/dev/random/randomdev_soft.c (working copy) > @@ -38,6 +38,7 @@ __FBSDID("$FreeBSD$"); > #include > #include > #include > +#include > #include > #include > #include > @@ -50,6 +51,7 @@ __FBSDID("$FreeBSD$"); > #include > #include >=20 > +#include > #include > #include >=20 > @@ -63,7 +65,7 @@ static int random_yarrow_poll(int event, > static int random_yarrow_block(int flag); > static void random_yarrow_flush_reseed(void); >=20 > -struct random_systat random_yarrow =3D { > +struct random_adaptor random_yarrow =3D { > .ident =3D "Software, Yarrow", > .init =3D random_yarrow_init, > .deinit =3D random_yarrow_deinit, > @@ -103,7 +105,7 @@ static int random_kthread_control =3D 0; > static struct proc *random_kthread_proc; >=20 > /* List for the dynamic sysctls */ > -struct sysctl_ctx_list random_clist; > +static struct sysctl_ctx_list random_clist; >=20 > /* ARGSUSED */ > static int > @@ -120,25 +122,20 @@ random_yarrow_init(void) > { > int error, i; > struct harvest *np; > - struct sysctl_oid *random_o, *random_sys_o, = *random_sys_harvest_o; > + struct sysctl_oid *random_sys_o, *random_sys_harvest_o; > enum esource e; >=20 > - random_o =3D SYSCTL_ADD_NODE(&random_clist, > - SYSCTL_STATIC_CHILDREN(_kern), > - OID_AUTO, "random", CTLFLAG_RW, 0, > - "Software Random Number Generator"); > - > - random_yarrow_init_alg(&random_clist, random_o); > + random_yarrow_init_alg(&random_clist); >=20 > random_sys_o =3D SYSCTL_ADD_NODE(&random_clist, > - SYSCTL_CHILDREN(random_o), > + SYSCTL_STATIC_CHILDREN(_kern_random), > OID_AUTO, "sys", CTLFLAG_RW, 0, > "Entropy Device Parameters"); >=20 > SYSCTL_ADD_PROC(&random_clist, > SYSCTL_CHILDREN(random_sys_o), > OID_AUTO, "seeded", CTLTYPE_INT | CTLFLAG_RW, > - &random_systat->seeded, 1, random_check_boolean, "I", > + &random_yarrow.seeded, 1, random_check_boolean, "I", > "Seeded State"); >=20 > random_sys_harvest_o =3D SYSCTL_ADD_NODE(&random_clist, > @@ -362,10 +359,10 @@ random_yarrow_write(void *buf, int count > void > random_yarrow_unblock(void) > { > - if (!random_systat->seeded) { > - random_systat->seeded =3D 1; > - selwakeuppri(&random_systat->rsel, PUSER); > - wakeup(random_systat); > + if (!random_yarrow.seeded) { > + random_yarrow.seeded =3D 1; > + selwakeuppri(&random_yarrow.rsel, PUSER); > + wakeup(&random_yarrow); > } > (void)atomic_cmpset_int(&arc4rand_iniseed_state, ARC4_ENTR_NONE, > ARC4_ENTR_HAVE); > @@ -377,10 +374,10 @@ random_yarrow_poll(int events, struct th > int revents =3D 0; > mtx_lock(&random_reseed_mtx); >=20 > - if (random_systat->seeded) > + if (random_yarrow.seeded) > revents =3D events & (POLLIN | POLLRDNORM); > else > - selrecord(td, &random_systat->rsel); > + selrecord(td, &random_yarrow.rsel); >=20 > mtx_unlock(&random_reseed_mtx); > return revents; > @@ -394,12 +391,12 @@ random_yarrow_block(int flag) > mtx_lock(&random_reseed_mtx); >=20 > /* Blocking logic */ > - while (!random_systat->seeded && !error) { > + while (!random_yarrow.seeded && !error) { > if (flag & O_NONBLOCK) > error =3D EWOULDBLOCK; > else { > printf("Entropy device is blocking.\n"); > - error =3D msleep(random_systat, > + error =3D msleep(&random_yarrow, > &random_reseed_mtx, > PUSER | PCATCH, "block", 0); > } > @@ -420,3 +417,30 @@ random_yarrow_flush_reseed(void) >=20 > random_yarrow_reseed(); > } > + > +static int > +yarrow_modevent(module_t mod, int type, void *unused) > +{ > + > + switch (type) { > + case MOD_LOAD: > + random_adaptor_register("yarrow", &random_yarrow); > + /* > + * For statically built kernels that contain both = random.ko and > + * *_rng.ko, this event handler will do nothing, since > + * random.ko is loaded after *_rng.ko's, and hence = hasn't yet > + * registered for this event. > + * > + * In case where both random.ko and *_rng.ko are built = as > + * modules, random.ko is loaded prior to *_rng.ko's (by > + * dependency). This event handler is there to delay = creation > + * of /dev/{u,}random and attachment of this *_rng.ko. > + */ > + EVENTHANDLER_INVOKE(random_adaptor_attach, = &random_yarrow); > + return (0); > + } > + > + return (EINVAL); > +} > + > +RANDOM_ADAPTOR_MODULE(yarrow, yarrow_modevent, 1); > Index: sys/dev/random/randomdev_soft.h > =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 > --- sys/dev/random/randomdev_soft.h (revision 253846) > +++ sys/dev/random/randomdev_soft.h (working copy) > @@ -72,10 +72,10 @@ void random_process_event(struct harvest > void random_yarrow_reseed(void); > void random_yarrow_unblock(void); >=20 > -void random_yarrow_init_alg(struct sysctl_ctx_list *, struct = sysctl_oid *); > +void random_yarrow_init_alg(struct sysctl_ctx_list *); > void random_yarrow_deinit_alg(void); >=20 > -extern struct random_systat random_yarrow; > +extern struct random_adaptor random_yarrow; > extern struct mtx random_reseed_mtx; >=20 > /* If this was c++, this would be a template */ > Index: sys/dev/random/yarrow.c > =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 > --- sys/dev/random/yarrow.c (revision 253846) > +++ sys/dev/random/yarrow.c (working copy) > @@ -41,6 +41,7 @@ __FBSDID("$FreeBSD$"); > #include >=20 > #include > +#include > #include > #include >=20 > @@ -101,7 +102,7 @@ random_process_event(struct harvest *eve > } >=20 > void > -random_yarrow_init_alg(struct sysctl_ctx_list *clist, struct = sysctl_oid *in_o) > +random_yarrow_init_alg(struct sysctl_ctx_list *clist) > { > int i; > struct sysctl_oid *random_yarrow_o; > @@ -110,7 +111,7 @@ random_yarrow_init_alg(struct sysctl_ctx > * have a very good clue about what they do! > */ > random_yarrow_o =3D SYSCTL_ADD_NODE(clist, > - SYSCTL_CHILDREN(in_o), > + SYSCTL_STATIC_CHILDREN(_kern_random), > OID_AUTO, "yarrow", CTLFLAG_RW, 0, > "Yarrow Parameters"); >=20 > Index: sys/i386/conf/GENERIC > =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 > --- sys/i386/conf/GENERIC (revision 253845) > +++ sys/i386/conf/GENERIC (working copy) > @@ -309,6 +309,7 @@ device loop # Network = loopback > device random # Entropy device > options PADLOCK_RNG # VIA Padlock RNG > options RDRAND_RNG # Intel Bull Mountain RNG > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > device vlan # 802.1Q VLAN support > device tun # Packet tunnel. > Index: sys/i386/conf/XBOX > =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 > --- sys/i386/conf/XBOX (revision 253845) > +++ sys/i386/conf/XBOX (working copy) > @@ -62,6 +62,7 @@ device pass # Passthrough = device (dire > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > #device tun # Packet tunnel. > #device md # Memory "disks" > Index: sys/i386/conf/XEN > =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 > --- sys/i386/conf/XEN (revision 253845) > +++ sys/i386/conf/XEN (working copy) > @@ -76,6 +76,7 @@ device pci > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > device tun # Packet tunnel. > device md # Memory "disks" > @@ -90,4 +91,3 @@ options AH_SUPPORT_AR5416 > # Be aware of the administrative consequences of enabling this! > # Note that 'bpf' is required for DHCP. > device bpf # Berkeley packet filter > - > Index: sys/ia64/conf/GENERIC > =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 > --- sys/ia64/conf/GENERIC (revision 253845) > +++ sys/ia64/conf/GENERIC (working copy) > @@ -198,6 +198,7 @@ device loop # Network = loopback > device md # Memory "disks" > device puc # Multi I/O cards and = multi-channel UARTs > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > device tun # Packet tunnel. > device uart # Serial port (UART) > device vlan # 802.1Q VLAN support > Index: sys/mips/conf/AR71XX_BASE > =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 > --- sys/mips/conf/AR71XX_BASE (revision 253845) > +++ sys/mips/conf/AR71XX_BASE (working copy) > @@ -24,7 +24,7 @@ makeoptions DEBUG=3D-g #Build kernel = with >=20 > # Build these as modules so small platform builds will have the > # modules already built. > -makeoptions MODULES_OVERRIDE=3D"random gpio ar71xx if_gif if_gre = if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip = wlan_ccmp wlan_rssadapt wlan_amrr ath ath_pci" > +makeoptions MODULES_OVERRIDE=3D"random yarrow_rng gpio ar71xx if_gif = if_gre if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep = wlan_tkip wlan_ccmp wlan_rssadapt wlan_amrr ath ath_pci" >=20 > options DDB > options KDB > @@ -115,6 +115,7 @@ device ether > device md > device bpf > device random > +options YARROW_RNG # Yarrow software RNG > device if_bridge > device gif # ip[46] in ip[46] tunneling = protocol > device gre # generic encapsulation - only = for IPv4 in IPv4 though atm > Index: sys/mips/conf/AR724X_BASE > =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 > --- sys/mips/conf/AR724X_BASE (revision 253845) > +++ sys/mips/conf/AR724X_BASE (working copy) > @@ -25,7 +25,7 @@ makeoptions DEBUG=3D-g #Build kernel = with >=20 > # Build these as modules so small platform builds will have the > # modules already built. > -makeoptions MODULES_OVERRIDE=3D"random gpio ar71xx if_gif if_gre = if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip = wlan_ccmp wlan_rssadapt wlan_amrr ath ath_pci hwpmc cam" > +makeoptions MODULES_OVERRIDE=3D"random yarrow_rng gpio ar71xx if_gif = if_gre if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep = wlan_tkip wlan_ccmp wlan_rssadapt wlan_amrr ath ath_pci hwpmc cam" >=20 > options DDB > options KDB > Index: sys/mips/conf/AR91XX_BASE > =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 > --- sys/mips/conf/AR91XX_BASE (revision 253845) > +++ sys/mips/conf/AR91XX_BASE (working copy) > @@ -20,7 +20,7 @@ files "../atheros/files.ar71xx" > hints "AR91XX_BASE.hints" >=20 > makeoptions DEBUG=3D-g #Build kernel with gdb(1) debug = symbols > -makeoptions MODULES_OVERRIDE=3D"random gpio ar71xx if_gif if_gre = if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep wlan_tkip = wlan_ccmp wlan_rssadapt wlan_amrr ath ath_ahb hwpmc" > +makeoptions MODULES_OVERRIDE=3D"random yarrow_rng gpio ar71xx if_gif = if_gre if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep = wlan_tkip wlan_ccmp wlan_rssadapt wlan_amrr ath ath_ahb hwpmc" >=20 > options DDB > options KDB > @@ -113,6 +113,7 @@ device ether > device md > device bpf > device random > +options YARROW_RNG # Yarrow software RNG > device if_bridge > device gpio > device gpioled > Index: sys/mips/conf/AR933X_BASE > =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 > --- sys/mips/conf/AR933X_BASE (revision 253845) > +++ sys/mips/conf/AR933X_BASE (working copy) > @@ -20,7 +20,7 @@ files "../atheros/files.ar71xx" > hints "AR933X_BASE.hints" >=20 > makeoptions DEBUG=3D-g #Build kernel with gdb(1) debug = symbols > -# makeoptions MODULES_OVERRIDE=3D"random gpio ar71xx if_gif = if_gre if_bridge bridgestp usb wlan wlan_xauth wlan_acl wlan_wep = wlan_tkip wlan_ccmp wlan_rssadapt wlan_amrr ath ath_ahb hwpmc" > +# makeoptions MODULES_OVERRIDE=3D"random yarrow_rng gpio = ar71xx if_gif if_gre if_bridge bridgestp usb wlan wlan_xauth wlan_acl = wlan_wep wlan_tkip wlan_ccmp wlan_rssadapt wlan_amrr ath ath_ahb hwpmc" > makeoptions MODULES_OVERRIDE=3D"" >=20 > options DDB > @@ -119,6 +119,7 @@ device ether > device md > device bpf > device random > +options YARROW_RNG # Yarrow software RNG > device if_bridge > device gpio > device gpioled > Index: sys/mips/conf/BERI_TEMPLATE > =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 > --- sys/mips/conf/BERI_TEMPLATE (revision 253845) > +++ sys/mips/conf/BERI_TEMPLATE (working copy) > @@ -55,4 +55,5 @@ device md > device ether > device loop > device random > +options YARROW_RNG # Yarrow software RNG > device snp > Index: sys/mips/conf/DIR-825 > =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 > --- sys/mips/conf/DIR-825 (revision 253845) > +++ sys/mips/conf/DIR-825 (working copy) > @@ -20,6 +20,7 @@ hints "DIR-825.hints" > # Since the kernel image must fit inside 1024KiB, we have to build = almost > # everything as modules. > nodevice random > +nooptions YARROW_RNG > nodevice gpio > nodevice gpioled > nodevice gif > Index: sys/mips/conf/GXEMUL > =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 > --- sys/mips/conf/GXEMUL (revision 253845) > +++ sys/mips/conf/GXEMUL (working copy) > @@ -51,6 +51,7 @@ device gxemul_ether > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > device tun # Packet tunnel. > device md # Memory "disks" > Index: sys/mips/conf/OCTEON1 > =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 > --- sys/mips/conf/OCTEON1 (revision 253845) > +++ sys/mips/conf/OCTEON1 (working copy) > @@ -256,6 +256,7 @@ device wi # = WaveLAN/Intersil/Symbol 80 > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > device vlan # 802.1Q VLAN support > device tun # Packet tunnel. > Index: sys/mips/conf/PB92 > =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 > --- sys/mips/conf/PB92 (revision 253845) > +++ sys/mips/conf/PB92 (working copy) > @@ -22,7 +22,7 @@ options AR71XX_ENV_UBOOT > # who already are using it without modifying the default flash layout) > # we need to cut down on a lot of things. >=20 > -makeoptions MODULES_OVERRIDE=3D"ath ath_pci ath_ahb bridgestp = if_bridge if_gif if_gre random wlan wlan_acl wlan_amrr wlan_ccmp = wlan_rssadapt wlan_tkip wlan_wep wlan_xauth usb ar71xx" > +makeoptions MODULES_OVERRIDE=3D"ath ath_pci ath_ahb bridgestp = if_bridge if_gif if_gre random yarrow_rng wlan wlan_acl wlan_amrr = wlan_ccmp wlan_rssadapt wlan_tkip wlan_wep wlan_xauth usb ar71xx" >=20 > hints "PB92.hints" > include "../atheros/std.ar71xx" > Index: sys/mips/conf/RT305X > =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 > --- sys/mips/conf/RT305X (revision 253845) > +++ sys/mips/conf/RT305X (working copy) > @@ -24,7 +24,7 @@ makeoptions MIPS_LITTLE_ENDIAN=3Ddefined > makeoptions KERNLOADADDR=3D0x80001000 >=20 > # Don't build any modules yet. > -makeoptions MODULES_OVERRIDE=3D"wlan_xauth wlan_wep wlan_tkip = wlan_acl wlan_amrr wlan_ccmp wlan_rssadapt random if_bridge bridgestp = msdosfs md ipfw dummynet libalias geom/geom_label ufs usb/uplcom usb/u3g = usb/umodem usb/umass usb/ucom cam zlib" > +makeoptions MODULES_OVERRIDE=3D"wlan_xauth wlan_wep wlan_tkip = wlan_acl wlan_amrr wlan_ccmp wlan_rssadapt random yarrow_rng if_bridge = bridgestp msdosfs md ipfw dummynet libalias geom/geom_label ufs = usb/uplcom usb/u3g usb/umodem usb/umass usb/ucom cam zlib" > makeoptions RT3052F >=20 > include "../rt305x/std.rt305x" > @@ -90,6 +90,7 @@ options MROUTING =20 > options IPFIREWALL_DEFAULT_TO_ACCEPT >=20 > device random > +options YARROW_RNG # Yarrow software RNG > device loop > # RT3050F, RT3052F have only pseudo PHYs, so mii not required > device rt > Index: sys/mips/conf/XLR64 > =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 > --- sys/mips/conf/XLR64 (revision 253845) > +++ sys/mips/conf/XLR64 (working copy) > @@ -84,6 +84,7 @@ device uart > # Pseudo > device loop > device random > +options YARROW_RNG # Yarrow software RNG > device md > device bpf >=20 > Index: sys/mips/conf/XLRN32 > =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 > --- sys/mips/conf/XLRN32 (revision 253845) > +++ sys/mips/conf/XLRN32 (working copy) > @@ -85,6 +85,7 @@ device uart > # Pseudo > device loop > device random > +options YARROW_RNG # Yarrow software RNG > device md > device bpf >=20 > Index: sys/mips/conf/std.SWARM > =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 > --- sys/mips/conf/std.SWARM (revision 253845) > +++ sys/mips/conf/std.SWARM (working copy) > @@ -42,6 +42,7 @@ device loop > device ether > device md > device random > +options YARROW_RNG # Yarrow software RNG >=20 > options USB_DEBUG > device usb > Index: sys/mips/conf/std.XLP > =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 > --- sys/mips/conf/std.XLP (revision 253845) > +++ sys/mips/conf/std.XLP (working copy) > @@ -65,6 +65,7 @@ makeoptions FDT_DTS_FILE=3Dxlp-basic.dts > # Pseudo > device loop > device random > +options YARROW_RNG # Yarrow software RNG > device md > device bpf >=20 > Index: sys/modules/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 > --- sys/modules/Makefile (revision 253845) > +++ sys/modules/Makefile (working copy) > @@ -254,6 +254,7 @@ SUBDIR=3D \ > ${_opensolaris} \ > oce \ > ${_padlock} \ > + ${_padlock_rng} \ > patm \ > ${_pccard} \ > ${_pcfclock} \ > @@ -280,6 +281,7 @@ SUBDIR=3D \ > ${_random} \ > rc4 \ > ${_rdma} \ > + ${_rdrand_rng} \ > re \ > reiserfs \ > rl \ > @@ -363,11 +365,14 @@ SUBDIR=3D \ > ${_x86bios} \ > ${_xe} \ > xl \ > + yarrow_rng \ > ${_zfs} \ > zlib \ >=20 > .if ${MACHINE_CPUARCH} =3D=3D "i386" || ${MACHINE_CPUARCH} =3D=3D = "amd64" > _filemon=3D filemon > +_padlock_rng=3D padlock_rng > +_rdrand_rng=3D rdrand_rng > .endif >=20 > .if ${MACHINE_CPUARCH} !=3D "powerpc" && ${MACHINE_CPUARCH} !=3D "arm" = && \ > Index: sys/modules/padlock_rng/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 > --- sys/modules/padlock_rng/Makefile (revision 0) > +++ sys/modules/padlock_rng/Makefile (working copy) > @@ -0,0 +1,10 @@ > +# $FreeBSD$ > + > +.PATH: ${.CURDIR}/../../dev/random > + > +KMOD=3D padlock_rng > + > +SRCS+=3D \ > + nehemiah.c > + > +.include >=20 > Property changes on: sys/modules/padlock_rng/Makefile > ___________________________________________________________________ > Added: svn:mime-type > ## -0,0 +1 ## > +text/plain > \ No newline at end of property > Added: svn:keywords > ## -0,0 +1 ## > +FreeBSD=3D%H > \ No newline at end of property > Added: svn:eol-style > ## -0,0 +1 ## > +native > \ No newline at end of property > Index: sys/modules/rdrand_rng/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 > --- sys/modules/rdrand_rng/Makefile (revision 0) > +++ sys/modules/rdrand_rng/Makefile (working copy) > @@ -0,0 +1,10 @@ > +# $FreeBSD$ > + > +.PATH: ${.CURDIR}/../../dev/random > + > +KMOD=3D rdrand_rng > + > +SRCS+=3D \ > + ivy.c > + > +.include >=20 > Property changes on: sys/modules/rdrand_rng/Makefile > ___________________________________________________________________ > Added: svn:eol-style > ## -0,0 +1 ## > +native > \ No newline at end of property > Added: svn:mime-type > ## -0,0 +1 ## > +text/plain > \ No newline at end of property > Added: svn:keywords > ## -0,0 +1 ## > +FreeBSD=3D%H > \ No newline at end of property > Index: sys/modules/yarrow_rng/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 > --- sys/modules/yarrow_rng/Makefile (revision 0) > +++ sys/modules/yarrow_rng/Makefile (working copy) > @@ -0,0 +1,19 @@ > +# $FreeBSD$ > + > +.PATH: ${.CURDIR}/../../dev/random > +.PATH: ${.CURDIR}/../../crypto/rijndael > + > +KMOD=3D yarrow_rng > + > +SRCS+=3D \ > + hash.c \ > + randomdev_soft.c \ > + rijndael-alg-fst.c \ > + rijndael-api-fst.c \ > + yarrow.c > + > +SRCS+=3D bus_if.h device_if.h > + > +CFLAGS+=3D -I${.CURDIR}/../.. > + > +.include >=20 > Property changes on: sys/modules/yarrow_rng/Makefile > ___________________________________________________________________ > Added: svn:mime-type > ## -0,0 +1 ## > +text/plain > \ No newline at end of property > Added: svn:keywords > ## -0,0 +1 ## > +FreeBSD=3D%H > \ No newline at end of property > Added: svn:eol-style > ## -0,0 +1 ## > +native > \ No newline at end of property > Index: sys/pc98/conf/GENERIC > =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 > --- sys/pc98/conf/GENERIC (revision 253845) > +++ sys/pc98/conf/GENERIC (working copy) > @@ -217,6 +217,7 @@ options AH_SUPPORT_AR5416 # enable AR54 > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > device vlan # 802.1Q VLAN support > device tun # Packet tunnel. > Index: sys/powerpc/conf/GENERIC > =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 > --- sys/powerpc/conf/GENERIC (revision 253845) > +++ sys/powerpc/conf/GENERIC (working copy) > @@ -144,6 +144,7 @@ device fxp # Intel = EtherExpress PRO/10 > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > device vlan # 802.1Q VLAN support > device tun # Packet tunnel. > Index: sys/powerpc/conf/GENERIC64 > =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 > --- sys/powerpc/conf/GENERIC64 (revision 253845) > +++ sys/powerpc/conf/GENERIC64 (working copy) > @@ -141,6 +141,7 @@ device fxp # Intel = EtherExpress PRO/10 > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > device vlan # 802.1Q VLAN support > device tun # Packet tunnel. > Index: sys/powerpc/conf/MPC85XX > =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 > --- sys/powerpc/conf/MPC85XX (revision 253845) > +++ sys/powerpc/conf/MPC85XX (working copy) > @@ -76,6 +76,7 @@ device pass > device pci > device quicc > device random > +options YARROW_RNG # Yarrow software RNG > #device rl > device scbus > device scc > Index: sys/powerpc/conf/WII > =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 > --- sys/powerpc/conf/WII (revision 253845) > +++ sys/powerpc/conf/WII (working copy) > @@ -72,6 +72,7 @@ makeoptions SC_DFLT_FONT=3Dcp437 > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > device vlan # 802.1Q VLAN support > device tun # Packet tunnel. > Index: sys/sparc64/conf/GENERIC > =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 > --- sys/sparc64/conf/GENERIC (revision 253845) > +++ sys/sparc64/conf/GENERIC (working copy) > @@ -215,6 +215,7 @@ device ath_rate_sample # SampleRate tx=20= > # Pseudo devices. > device loop # Network loopback > device random # Entropy device > +options YARROW_RNG # Yarrow software RNG > device ether # Ethernet support > device vlan # 802.1Q VLAN support > device tun # Packet tunnel. > Index: tools/tools/sysdoc/sysdoc.sh > =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 > --- tools/tools/sysdoc/sysdoc.sh (revision 253845) > +++ tools/tools/sysdoc/sysdoc.sh (working copy) > @@ -88,7 +88,7 @@ EOF > # tunables in our tunables.mdoc file and generate > # the final 'inner circle' of our manual page. > markup_create() { > - sort < _names | \ > + sort -u < _names | \ > xargs -n 1 /bin/sh ./sysctl.sh \ > > markup.file \ > 2> tunables.TODO > @@ -238,9 +238,13 @@ if [ -z "$LOCATION" ] ; > && for x in `find $LOCATION -name '*.kld'` \ > $LOCATION/kernel; \ > do nm $x | \ > - grep ' sysctl___' | uniq | \ > - sed 's/sysctl___//g' | sed 's/_/./g' | \ > - awk {'print $3'} > _names; > + sed -n '/sysctl___/ { > + 's/[\.a-z_]*sysctl___//g' > + 's/_/./g' > + p > + }' | \ > + awk {'print $3'} | \ > + sort -u > _names; > done; > markup_create > page_create > Index: tools/tools/sysdoc/tunables.mdoc > =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 > --- tools/tools/sysdoc/tunables.mdoc (revision 253845) > +++ tools/tools/sysdoc/tunables.mdoc (working copy) > @@ -1093,6 +1093,13 @@ line programs. > kern.quantum >=20 > --- > +kern.random.adaptors > +str > + > +Displays registered PRNG adaptors (sources). > +This is a read-only variable. > + > +--- > kern.random.sys.burst >=20 > --- >=20 > --=20 > -- David (obrien@FreeBSD.org) > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to = "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 19:25:59 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3A721F0A for ; Thu, 8 Aug 2013 19:25:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 06A132DAA for ; Thu, 8 Aug 2013 19:25:58 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id x14so2448619ief.26 for ; Thu, 08 Aug 2013 12:25:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=IUXji+VWca5xoxKFdH2rdA2BeJhkPOxs8HWA60HVZAk=; b=V/eHvmvrWo0L9d65BFtssy6WHGmb7ncEdQYHzxLg6q5JHPVKosnxaZMuvz2rXRk7Cp N95iwy0wzvd/Oyg5P/vbCvH3cmw6vwPeGh51T7+hLpXmofnZcSMgdqPvAiR7DZY+BOG4 J9rjMXL8BPm8+o/Tvi+ZzzOn1jHO0ZF034C2cAg9wzQanzDrnn36Ch5D6GlNdbPppVM/ Aq5DxxQGbGDnJNnvckk9LzGt8Lpmiz+OQp5XY7R80xmkZnJS/1KU3g+Rf7p9tMjntm/P eKo9WjsYMlk1kU7kAF0P/L0ZWPxlciN3rVXddEW43bJKRKaTGp5njPM8LtNsvE3iWZKb fuXA== X-Gm-Message-State: ALoCoQnG0keu9uGvAIlQBgLSPB6643GTPoExe6mHRO+bQCqe7tI7ChRRa4pH6Do1nhrI2Y5Qmvqk X-Received: by 10.43.0.67 with SMTP id nl3mr2884105icb.2.1375989958191; Thu, 08 Aug 2013 12:25:58 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id cl4sm46914igc.1.2013.08.08.12.25.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 12:25:57 -0700 (PDT) Sender: Warner Losh Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <5203968D.7060508@freebsd.org> Date: Thu, 8 Aug 2013 13:25:54 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7018AAA9-0A88-430F-96B7-867E5F529B36@bsdimp.com> References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <5203968D.7060508@freebsd.org> To: Andrey Chernov X-Mailer: Apple Mail (2.1085) Cc: Arthur Mesh , Steve Kargl , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:25:59 -0000 On Aug 8, 2013, at 7:01 AM, Andrey Chernov wrote: > On 08.08.2013 0:20, Peter Wemm wrote: >> That's the main point here. >>=20 >> If I'm running on a working system, I have a reasonable expectation >> that the kernel config I was using yesterday will work sufficiently >> tomorrow that I won't get hosed by doing a 'svn update && make >> buildkernel && make installkernel'. >>=20 >> If that's not the case and there is a required change in order to not >> hose your system then POLA dictates that not making the required >> changes causes a build failure. >>=20 >> There's more leeway on head than a stable branch, but remember that >> when people upgrade from 9.x to 10.x they tend to take their 9.x >> kernel configs and make whatever changes are needed to get it to >> build. The 9-stable -> 10-release config path needs to catch fatal >> errors like this at build time. >>=20 >> Patching GENERIC isn't a complete solution. It doesn't solve the >> 'yesterday it worked, today it's a brick' problem. >=20 > Many years ago I already suggest to de-modularize random (making it = not > optional), with fallback to yarrow if hardware RNGs can't be probed or > not configured. I think that the 'fallback to yarrow' is necessary here. Warner P.S. Where 'yarrow' can easily be read as 'the best software RNG we've = implemented' should that change to something better in the future. From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 19:32:28 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 630BF1F5 for ; Thu, 8 Aug 2013 19:32:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2F6612E0E for ; Thu, 8 Aug 2013 19:32:27 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id x14so2461342ief.26 for ; Thu, 08 Aug 2013 12:32:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=rhpRaROoxLnGf68SPkNXfmb4LZ0b5i+7nm80RqUSAVc=; b=i/3l3PhwZrZaerI6+EqGYOTIQhXUkxu/eHj4KZLHGTuMj4WO9MuLia5VlDJmO1DXfv k2Z2mLbI13VYliZIQvcfaB6/H3ycKPQZfC+dbcENQHftrStYDA24EKg+BmjN5VzpILVK DgXTEuVM1n1XgWfFR/nBUJgsVKw9cGWpRwVHl6pufUg788pxRquPgFO0lHQqPHZ9egj6 AoJWCY1Nt3hoC0/Qh1acoJt29rbRGWmPY4R91lAjzf0gOuLlZrb1fUAo9QmKFOXhMDQo whNmO1ByXT/TcPr2PwZHsfyWB+d9bvhDUb2gcvupHQVqCbMaKvWNB4kkc8IcrZHTLj6q MLlg== X-Gm-Message-State: ALoCoQmn9iECHEHl4ffWSX4G5MSIYhCCYypop7pDUKUgypa9c4A8kGq5+aPjwByleCvBDawlPOx9 X-Received: by 10.50.47.20 with SMTP id z20mr264743igm.34.1375989847779; Thu, 08 Aug 2013 12:24:07 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id nm17sm8510394igb.5.2013.08.08.12.24.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 12:24:06 -0700 (PDT) Sender: Warner Losh Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <201308081023.53040.jhb@freebsd.org> Date: Thu, 8 Aug 2013 13:24:03 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <201308081023.53040.jhb@freebsd.org> To: John Baldwin X-Mailer: Apple Mail (2.1085) Cc: Arthur Mesh , Steve Kargl , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:32:28 -0000 On Aug 8, 2013, at 8:23 AM, John Baldwin wrote: > On Wednesday, August 07, 2013 4:20:29 pm Peter Wemm wrote: >> On Wed, Aug 7, 2013 at 12:27 PM, Steve Kargl >> wrote: >>> On Wed, Aug 07, 2013 at 11:28:58AM -0700, David O'Brien wrote: >>>>=20 >>>> * Make Yarrow an optional kernel component -- enabled by = "YARROW_RNG" >>>> option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c >>>> comprise yarrow. random(4) device doesn't really depend on >>>> rijndael-*. Yarrow, however, does. >>>>=20 >>>> * If the kernel doesn't have any random_adaptor adapters present = then >>>> the creation of /dev/random is postponed until next random_adaptor >>>> is kldload'ed. >>>=20 >>> My kernel config files have included the following 2 lines for >>> ages: >>>=20 >>> makeoptions NO_MODULES >>> device random >>>=20 >>> If I try to build a new kernel under your scheme, will the >>> build die with an error about a missing option? If the answer >>> is 'no', then the yarrow adaptor should be opt-out. >>=20 >> That's the main point here. >>=20 >> If I'm running on a working system, I have a reasonable expectation >> that the kernel config I was using yesterday will work sufficiently >> tomorrow that I won't get hosed by doing a 'svn update && make >> buildkernel && make installkernel'. >>=20 >> If that's not the case and there is a required change in order to not >> hose your system then POLA dictates that not making the required >> changes causes a build failure. >>=20 >> There's more leeway on head than a stable branch, but remember that >> when people upgrade from 9.x to 10.x they tend to take their 9.x >> kernel configs and make whatever changes are needed to get it to >> build. The 9-stable -> 10-release config path needs to catch fatal >> errors like this at build time. >>=20 >> Patching GENERIC isn't a complete solution. It doesn't solve the >> 'yesterday it worked, today it's a brick' problem. >=20 > The counter to this is that in the recent past, any suggestion to add = anything > to DEFAULTS was met with "that's the wrong way". In actual fact, = changes > to GENERIC happen quite often, and we often break older kernel configs = from > older branches (ATA_CAM is no longer in 10 for example). I'm not sure = I buy=20 > the argument that we can never break kernel configs from older = branches. >=20 > I also think that NO_FOO options aren't the way to go and that we = should=20 > always create "positive" options, but add them to GENERIC when making = a=20 > previously standard thing optional. I think adding things to DEFAULTS = should=20 > be rarely done, if ever. For the embedded kernels, where std.* take the place of the = sledge-hammer DEFAULTS, they are often the right place to put options = that will be the same for all kernels due to hardware constraints or = dictations. In this case, the port maintainers would know if there's a = hardware RNG or not on the chip, and if not put it into the appropriate = std.foo file. Of course, the fail stupid part of this patch is an even more = fundamental flaw in this patch, but I digress... Warner Warner From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 19:38:31 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 81A5133D; Thu, 8 Aug 2013 19:38:31 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 43C842E50; Thu, 8 Aug 2013 19:38:31 +0000 (UTC) Received: from [2001:470:9174:1:7192:47aa:bfbe:3889] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V7W2U-000P5q-Eo; Thu, 08 Aug 2013 20:38:27 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8BBE82C0-E265-4E68-A573-3066882F4A93"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <7018AAA9-0A88-430F-96B7-867E5F529B36@bsdimp.com> Date: Thu, 8 Aug 2013 20:38:09 +0100 Message-Id: <50BE6942-CC39-413C-8E14-C6B93440901B@grondar.org> References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <5203968D.7060508@freebsd.org> <7018AAA9-0A88-430F-96B7-867E5F529B36@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1508) X-SA-Score: -1.0 Cc: Arthur Mesh , secteam@freebsd.org, Steve Kargl , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 19:38:31 -0000 --Apple-Mail=_8BBE82C0-E265-4E68-A573-3066882F4A93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 8 Aug 2013, at 20:25, Warner Losh wrote: >=20 > On Aug 8, 2013, at 7:01 AM, Andrey Chernov wrote: >=20 >> Many years ago I already suggest to de-modularize random (making it = not >> optional), with fallback to yarrow if hardware RNGs can't be probed = or >> not configured. >=20 > I think that the 'fallback to yarrow' is necessary here. My current inclination is to make Yarrow the basic device (or "Fortuna = Lite", but that is a problem for MUCH later), and make the hardware = devices feed Yarrow, if they are present. Fortuna will then be an optional replacement for Yarrow, and it will = keep the ability to source input from hardware RNGs if they are present. I still want to get back something like the original get_cyclecount(); = simple and quick. I don't care what its called, but out doesn't need to = be the massive thing that the current get_cyclecount() has grown to be = on x86. rdtsc(), I think it was. > P.S. Where 'yarrow' can easily be read as 'the best software RNG we've = implemented' should that change to something better in the future. While Fortuna matures, I'd like to keep it as an option, not make it a = replacement. M --=20 Mark R V Murray --Apple-Mail=_8BBE82C0-E265-4E68-A573-3066882F4A93 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUgPzqN58vKOKE6LNAQryQAQAuTLK8DFzVd/O4iCHc7PAzbHmOC7CVTIU Igw82LLB+zgQG88UkwVuf2oZb3l9/u3Atgb2L+3dQpAQm1/oWKHrQA2b/pincHgJ 5Dp7y2GvLwPI2dRV2DG8W6Ecxl5dqWOsuQAhVuI/cDkxSHBfuWjCsylETBCjCxLt K4C/GN532zQ= =vaAm -----END PGP SIGNATURE----- --Apple-Mail=_8BBE82C0-E265-4E68-A573-3066882F4A93-- From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 20:06:00 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4FF6A803 for ; Thu, 8 Aug 2013 20:06:00 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 09FA32FD7 for ; Thu, 8 Aug 2013 20:05:59 +0000 (UTC) Received: from Julian-MBP3.local (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r78K5nMf092158 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 8 Aug 2013 13:05:52 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <5203FA18.20403@freebsd.org> Date: Fri, 09 Aug 2013 04:05:44 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: Re: Reliable process tracking References: <20130804134658.GC35080@stack.nl> <20130807201934.GA4918@stack.nl> In-Reply-To: <20130807201934.GA4918@stack.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 20:06:00 -0000 On 8/8/13 4:19 AM, Jilles Tjoelker wrote: > On Mon, Aug 05, 2013 at 01:13:10PM +0200, Edward Tomasz Napierała wrote: >> Wiadomość napisana przez Jilles Tjoelker w dniu 4 sie 2013, o godz. 15:46: >>> When shutting down a service or requesting status, rc.subr currently >>> uses a combination of pidfiles and process names. This is fairly but not >>> completely reliable once it is set up correctly (which can take a lot of >>> work and possibly patching the daemon to use pidfile(3) from our >>> libutil). It is also incapable of killing multiprocess daemons such as >>> CGI web servers without cooperation of the daemon. >>> I think what is needed here is a facility that marks a process and all >>> of its descendants. Removing the mark should be a privileged or at least >>> an unusual operation; no unprivileged function specified by POSIX such >>> as setsid() should do this. >> I've actually thought about that when I added setloginclass(2). It's >> trivial to modify rc.subr to use su(8) to set login class for each >> service. It should be trivial to modify pkill(1) and killall(1) to >> add "-c" option to kill all processes in a given login class. > There are some problems with su -c: > > * It refuses to set a login class name that is not in /etc/login.conf. > Given that multiple instances of a service should each have their own > kernel login class, it may make sense to allow specifying the > login.conf entry separate from the kernel login class. I've been pondering the possibility of appending a universe (jail) number to the UIDS, PIDS and various other things. (classes maybe?). It wouldn't have to be everywhere, but ther eare a number of places where comparisons would DTRT if they were comparing "my_jail+my_uid" with "his_jail+his_uid", instead of just the UIDs. It would also help with the "multiple roots" problem, and might simplify some of the current code. Unfortunately we already extend PIDS to make thread IDs but we could still grab a bunch of bits way up the top end to express jail-IDs. > > * It always inserts an intermediate process to shut down the PAM session. > This is not needed to start a simple daemon but not that harmful apart > from performance. > >> Two caveats: >> 1. Login classes, just like UIDs, are global, not per jail. This means when >> you want to kill all processees in a login class, you should probably use >> "-j" option to limit it to a given jail, e.g. jail 0. > True. > >> 2. I'm not sure if pkill(1) has any special way of handling this, but there is >> an obvious race condition between iterating over processes in userland >> in pkill(1) and quickly forking processes to kill. Perhaps we should have >> some kind of syscall to do it in a race-free way? > Yes. > From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 20:55:17 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 20F0DEFB; Thu, 8 Aug 2013 20:55:17 +0000 (UTC) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 085062259; Thu, 8 Aug 2013 20:55:17 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r78KtGFc072688; Thu, 8 Aug 2013 20:55:16 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r78KtGB9072685; Thu, 8 Aug 2013 20:55:16 GMT (envelope-from obrien) Date: Thu, 8 Aug 2013 13:55:14 -0700 From: "David O'Brien" To: Scott Long Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130808205514.GA95000@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Scott Long , secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh References: <20130807183516.GC79319@dragon.NUXI.org> <1EDB5C8E-5755-4A8A-89F1-A64412080744@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1EDB5C8E-5755-4A8A-89F1-A64412080744@yahoo.com> X-Operating-System: FreeBSD 10.0-CURRENT X-MUA-Host: dragon.NUXI.org X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 20:55:17 -0000 On Wed, Aug 07, 2013 at 05:07:15PM -0700, Scott Long wrote: > We only compile and deploy a whitelist subset of modules, so the PRNG > modules were not compiled into the kernel nor present in /boot. When the > machine came up, it paused waiting for keyboard input. In one iteration, it > released the hold after about 100 characters of quick typing. Do you have any random(4) related local changes? I ask because the FreeBSD kernel does not block due to either a missing a /dev/random device, nor yarrow being not seeded. I'd like to understand how you experienced what seems to be blocking due to being not-seeded in a FreeBSD 10 (or -STABLE) kernel. > In the first iteration, even after the system continued, various things > complained and/or failed with a complaint of there being no > /dev/random. named was one thing, but I know there were others. It sounds like this is not a headless machine, correct? I'll enable named on my test machine and see if I get the whine about lack of /dev/random. Note that OpenSSL (and thus OpenSSH) handle the lack of /dev/random. (and do so without warning or other indication) Are there other non-default daemons you enable. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 21:15:19 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4B0A7285; Thu, 8 Aug 2013 21:15:19 +0000 (UTC) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 13CD62394; Thu, 8 Aug 2013 21:15:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r78LFIpn077252; Thu, 8 Aug 2013 21:15:18 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r78LFI3l077249; Thu, 8 Aug 2013 21:15:18 GMT (envelope-from obrien) Date: Thu, 8 Aug 2013 14:15:17 -0700 From: "David O'Brien" To: Warner Losh Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130808211517.GB95000@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Warner Losh , secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh References: <20130807182858.GA79286@dragon.NUXI.org> <223174A5-A146-4969-A3CF-6923EF7ECCF2@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <223174A5-A146-4969-A3CF-6923EF7ECCF2@bsdimp.com> X-Operating-System: FreeBSD 10.0-CURRENT X-MUA-Host: dragon.NUXI.org X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:15:19 -0000 On Thu, Aug 08, 2013 at 01:20:19PM -0600, Warner Losh wrote: > The sheer number of config files you changed says this is a bad idea, > or you are during something very wrong. Why? That's the sheer number of config files that have "device random" in them. How it reasonable for "device random" to be in them but not random(4) options? We did not like having to change so many config files -- the ARM kernel configs seems to be in need of additional refactoring. > Also, you bogusly changed way too many config files rather than the > underlying std.* files for the ARM port. If that is the case, why isn't "device random" in the std.* files? Please address that before saying that random(4) options should live somewhere else than where "device random" lives. > What's wrong with having yarrow as the default, fallback mechanism. And > why do you have a design that seems to force one, and only one, into > the kernel? The way it is now we fail bad rather than fail to yarrow > fallback. This seems unwise. How does it force 1 and only 1 into the kernel? If there were some MIPS or ARM HW they would also be in the kernel. When markm@ completes his Fortuna work, it could (and likely would) also live beside Yarrow. Or a NIST SP 800-90-A compliant HMAC_DRBG can also live in the kernel beside Yarrow (and Fortuna). Obviously at the point of having more than one SW PRNG we'll have a selection mechanism to "break ties". Right now the code only handles that for HW. > I haven't read the code in detail, but I don't see how I'd override > the CPU's random number unit with one from a plug-in board when it is > present. Please read the code to see how that is handled in sys/dev/random/probe.c:random_ident_hardware(). Note that my commit did not change the logic here (just updated the implementation of it). It's the same logic we've had since 2004 (r128059 and updated in 2012(r240135)). -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 21:16:59 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 37CA23DD; Thu, 8 Aug 2013 21:16:59 +0000 (UTC) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1B1E823AE; Thu, 8 Aug 2013 21:16:59 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r78LGwSW077368; Thu, 8 Aug 2013 21:16:58 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r78LGveJ077365; Thu, 8 Aug 2013 21:16:57 GMT (envelope-from obrien) Date: Thu, 8 Aug 2013 14:16:57 -0700 From: "David O'Brien" To: Mark R V Murray Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130808211657.GC95000@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Mark R V Murray , Warner Losh , Arthur Mesh , secteam@freebsd.org, Steve Kargl , freebsd-arch@freebsd.org References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <5203968D.7060508@freebsd.org> <7018AAA9-0A88-430F-96B7-867E5F529B36@bsdimp.com> <50BE6942-CC39-413C-8E14-C6B93440901B@grondar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50BE6942-CC39-413C-8E14-C6B93440901B@grondar.org> X-Operating-System: FreeBSD 10.0-CURRENT X-MUA-Host: dragon.NUXI.org X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , Steve Kargl , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:16:59 -0000 On Thu, Aug 08, 2013 at 08:38:09PM +0100, Mark R V Murray wrote: > My current inclination is to make Yarrow the basic device (or "Fortuna > Lite", but that is a problem for MUCH later), and make the hardware > devices feed Yarrow, if they are present. Our approach is mechanism over policy. That is, give the user the choice of if their HW should be used directly or fed into the SW PRNG. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 21:19:59 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 24CB04FA; Thu, 8 Aug 2013 21:19:59 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB91423D5; Thu, 8 Aug 2013 21:19:58 +0000 (UTC) Received: from [2001:470:9174:1:7192:47aa:bfbe:3889] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V7Xch-000PEn-5B; Thu, 08 Aug 2013 22:19:56 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_34F8FED9-9995-41A2-B3F2-4518602F8353"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <20130808211657.GC95000@dragon.NUXI.org> Date: Thu, 8 Aug 2013 22:19:46 +0100 Message-Id: <94E41175-EF09-47D1-9661-9AF04E8FA9A0@grondar.org> References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <5203968D.7060508@freebsd.org> <7018AAA9-0A88-430F-96B7-867E5F529B36@bsdimp.com> <50BE6942-CC39-413C-8E14-C6B93440901B@grondar.org> <20130808211657.GC95000@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1508) X-SA-Score: -1.0 Cc: Arthur Mesh , Steve Kargl , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:19:59 -0000 --Apple-Mail=_34F8FED9-9995-41A2-B3F2-4518602F8353 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 8 Aug 2013, at 22:16, "David O'Brien" wrote: > On Thu, Aug 08, 2013 at 08:38:09PM +0100, Mark R V Murray wrote: >> My current inclination is to make Yarrow the basic device (or "Fortuna >> Lite", but that is a problem for MUCH later), and make the hardware >> devices feed Yarrow, if they are present. > > Our approach is mechanism over policy. That is, give the user the > choice of if their HW should be used directly or fed into the SW PRNG. I don't see a problem with that either, as long as there are no nasty surprises like the possibility of getting no RNG at all, and not being in a position to notice. M -- Mark R V Murray --Apple-Mail=_34F8FED9-9995-41A2-B3F2-4518602F8353 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUgQLet58vKOKE6LNAQrT0QP9El0WPf7oFuzBGCHqDScozZCMtLP81c/A i+RGW4w5y6zJsOEqgd6osxu+zUUoAxRa4gBP1lcj3HKu23G+66Uv2VdrNGvfoWrJ uqdSxsAus1sRqFpAIv8D8qg/+BkN+jAbkbY/iaBnrAKi90MZ0WGn4pdXA6VgQTD8 v+dpbKqe6YU= =T90A -----END PGP SIGNATURE----- --Apple-Mail=_34F8FED9-9995-41A2-B3F2-4518602F8353-- From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 21:22:46 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7E76C628; Thu, 8 Aug 2013 21:22:46 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 3FE9B242D; Thu, 8 Aug 2013 21:22:46 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V7XfP-000PFH-FU; Thu, 08 Aug 2013 22:22:44 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F2A70419-AB93-4FE9-A977-8C37366DA750"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <20130808205514.GA95000@dragon.NUXI.org> Date: Thu, 8 Aug 2013 22:22:42 +0100 Message-Id: <1F5C260F-DA73-4D71-BB4B-E749BA9DEB57@grondar.org> References: <20130807183516.GC79319@dragon.NUXI.org> <1EDB5C8E-5755-4A8A-89F1-A64412080744@yahoo.com> <20130808205514.GA95000@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: Arthur Mesh , Scott Long , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:22:46 -0000 --Apple-Mail=_F2A70419-AB93-4FE9-A977-8C37366DA750 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 8 Aug 2013, at 21:55, David O'Brien wrote: > On Wed, Aug 07, 2013 at 05:07:15PM -0700, Scott Long wrote: >> We only compile and deploy a whitelist subset of modules, so the PRNG >> modules were not compiled into the kernel nor present in /boot. When = the >> machine came up, it paused waiting for keyboard input. In one = iteration, it >> released the hold after about 100 characters of quick typing. >=20 > Do you have any random(4) related local changes? I ask because the > FreeBSD kernel does not block due to either a missing a /dev/random > device, nor yarrow being not seeded. >=20 > I'd like to understand how you experienced what seems to be blocking > due to being not-seeded in a FreeBSD 10 (or -STABLE) kernel. Mechanism exists, but its disabled. I'd like to re-enable it. Look for "seeded =3D 1" in randomdev_soft.c, and see what that "seeded" variable does. M --=20 Mark R V Murray --Apple-Mail=_F2A70419-AB93-4FE9-A977-8C37366DA750 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUgQMIt58vKOKE6LNAQrNjgP/TFlESFA6djUsb3sY16vsiaP0Kh4XzREc kRn+kZZoQcVwKQwW0cRytu5jgabTYAXzRs10h6fQpni+/PhrwC5zNbXiGtWn0X53 m/9zOieIlZ960P0kJtZ6ep2tbzGrkDE9UNVbcvc/qjEKP0ptOASTkLI/cN9028BC Ml8IA8i2oww= =aw16 -----END PGP SIGNATURE----- --Apple-Mail=_F2A70419-AB93-4FE9-A977-8C37366DA750-- From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 21:34:50 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C350F8FA; Thu, 8 Aug 2013 21:34:50 +0000 (UTC) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 915CE24C4; Thu, 8 Aug 2013 21:34:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r78LYonu081194; Thu, 8 Aug 2013 21:34:50 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r78LYoGi081191; Thu, 8 Aug 2013 21:34:50 GMT (envelope-from obrien) Date: Thu, 8 Aug 2013 14:34:49 -0700 From: "David O'Brien" To: Steve Kargl Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130808213449.GD95000@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Steve Kargl , secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130807192736.GA7099@troutmask.apl.washington.edu> X-Operating-System: FreeBSD 10.0-CURRENT X-MUA-Host: dragon.NUXI.org X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:34:50 -0000 On Wed, Aug 07, 2013 at 12:27:36PM -0700, Steve Kargl wrote: > On Wed, Aug 07, 2013 at 11:28:58AM -0700, David O'Brien wrote: > > * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" > > option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c .. > My kernel config files have included the following 2 lines for > ages: > makeoptions NO_MODULES > device random > > If I try to build a new kernel under your scheme, will the > build die with an error about a missing option? You haven't given enough information to answer the question. Your kernel config does not have just those two lines. Is there an "include GENERIC" or something else above it? What is your full kernel config? > If the answer > is 'no', then the yarrow adaptor should be opt-out. There is no build issue (i.e., missing symbols). "device random" in the changeset is just the device (/dev/[u]random) implimentation. The many RNG's that provide the output. Do you really not read UPDATING and the release notes when you upgrade to to a .0 release? How did you learn about other config lines I'm sure you've changed over th years. e.g., options GEOM_PART_*, options SCHED_ULE, options NFSCL, options NFSD, any of the new gigE NIC's added over the past decade, removal of device ata & device atadisk, and removal of non-locked/MPSAFE drivers are things I can think of that you've likely added(removed) to your config over time. Lack of some of those would not cause a build break or config warning, but would have resulted in a less functional kernel. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 21:40:34 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 7BC2AC54; Thu, 8 Aug 2013 21:40:34 +0000 (UTC) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5FB67252A; Thu, 8 Aug 2013 21:40:34 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r78LeYLW081357; Thu, 8 Aug 2013 21:40:34 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r78LeXUf081353; Thu, 8 Aug 2013 21:40:33 GMT (envelope-from obrien) Date: Thu, 8 Aug 2013 14:40:33 -0700 From: "David O'Brien" To: Mark R V Murray Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130808214033.GE95000@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Mark R V Murray , Scott Long , Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org References: <20130807183516.GC79319@dragon.NUXI.org> <1EDB5C8E-5755-4A8A-89F1-A64412080744@yahoo.com> <20130808205514.GA95000@dragon.NUXI.org> <1F5C260F-DA73-4D71-BB4B-E749BA9DEB57@grondar.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F5C260F-DA73-4D71-BB4B-E749BA9DEB57@grondar.org> X-Operating-System: FreeBSD 10.0-CURRENT X-MUA-Host: dragon.NUXI.org X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , Scott Long , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:40:34 -0000 On Thu, Aug 08, 2013 at 10:22:42PM +0100, Mark R V Murray wrote: > Mechanism exists, but its disabled. I'd like to re-enable it. Look for > "seeded = 1" in randomdev_soft.c, and see what that "seeded" variable > does. Hi Mark, I'm not sure what you're saying here. That we could block at boot for reason of the PRGN not being seeded if desired? Or that we start seeded and thus never get unseeded? -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 21:49:41 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9313DA1; Thu, 8 Aug 2013 21:49:41 +0000 (UTC) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7A86525A7; Thu, 8 Aug 2013 21:49:41 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r78LnfVJ082995; Thu, 8 Aug 2013 21:49:41 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r78LnfiE082992; Thu, 8 Aug 2013 21:49:41 GMT (envelope-from obrien) Date: Thu, 8 Aug 2013 14:49:40 -0700 From: "David O'Brien" To: secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh Subject: [paritical] random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130808214940.GF95000@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh References: <20130807182858.GA79286@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130807182858.GA79286@dragon.NUXI.org> X-Operating-System: FreeBSD 10.0-CURRENT X-MUA-Host: dragon.NUXI.org X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:49:41 -0000 On Wed, Aug 07, 2013 at 11:28:58AM -0700, David O'Brien (@FreeBSD) wrote: > Here is a patch that improves the ability to add RNG's to the system, > even /usr/src-external as a kernel modules by creating a random(4) plugin > infrastructure. so@ has approved part of this changeset to be committed now. The patch has mostly lost the above ability, but here's the diff: Index: share/man/man4/random.4 =================================================================== --- share/man/man4/random.4 (revision 253845) +++ share/man/man4/random.4 (working copy) @@ -23,7 +23,7 @@ .\" .\" $FreeBSD$ .\" -.Dd September 7, 2012 +.Dd August 7, 2013 .Dt RANDOM 4 .Os .Sh NAME @@ -43,6 +43,13 @@ The device will probe for certain hardware entropy sources, and use these in preference to the fallback, which is a generator implemented in software. +If the kernel environment MIB's +.Va hw.nehemiah_rng_enable +or +.Va hw.ivy_rng_enable +are set to +.Dq Li 0 , +the associated hardware entropy source will be ignored. .Pp If the device is using the software generator, @@ -74,6 +81,7 @@ device, use the command line: .Pp which results in something like: .Bd -literal -offset indent +kern.random.adaptors: yarrow kern.random.sys.seeded: 1 kern.random.sys.harvest.ethernet: 1 kern.random.sys.harvest.point_to_point: 1 @@ -89,7 +97,9 @@ kern.random.yarrow.slowoverthresh: 2 (These would not be seen if a hardware generator is present.) .Pp -All settings are read/write. +Other than +.Dl kern.random.adaptors +all settings are read/write. .Pp The .Va kern.random.sys.seeded Index: sys/conf/files =================================================================== --- sys/conf/files (revision 253845) +++ sys/conf/files (working copy) @@ -2032,6 +2032,7 @@ rt2860.fw optional rt2860fw | ralfw \ dev/random/harvest.c standard dev/random/hash.c optional random dev/random/probe.c optional random +dev/random/random_adaptors.c standard dev/random/randomdev.c optional random dev/random/randomdev_soft.c optional random dev/random/yarrow.c optional random Index: sys/dev/random/ivy.c =================================================================== --- sys/dev/random/ivy.c (revision 253846) +++ sys/dev/random/ivy.c (working copy) @@ -28,16 +28,19 @@ #include __FBSDID("$FreeBSD$"); -#include "opt_cpu.h" - -#ifdef RDRAND_RNG - #include #include +#include #include +#include #include #include #include + +#include +#include + +#include #include #define RETRY_COUNT 10 @@ -46,7 +49,7 @@ static void random_ivy_init(void); static void random_ivy_deinit(void); static int random_ivy_read(void *, int); -struct random_systat random_ivy = { +struct random_adaptor random_ivy = { .ident = "Hardware, Intel IvyBridge+ RNG", .init = random_ivy_init, .deinit = random_ivy_deinit, @@ -114,4 +117,28 @@ random_ivy_read(void *buf, int c) return (c - count); } +static int +rdrand_modevent(module_t mod, int type, void *unused) +{ + + switch (type) { + case MOD_LOAD: + if (cpu_feature2 & CPUID2_RDRAND) { + random_adaptor_register("rdrand", &random_ivy); + EVENTHANDLER_INVOKE(random_adaptor_attach, &random_ivy); + return (0); + } else { +#ifndef KLD_MODULE + if (bootverbose) #endif + printf( + "%s: RDRAND feature is not present on this CPU\n", + random_ivy.ident); + return (0); + } + } + + return (EINVAL); +} + +RANDOM_ADAPTOR_MODULE(random_rdrand, rdrand_modevent, 1); Index: sys/dev/random/nehemiah.c =================================================================== --- sys/dev/random/nehemiah.c (revision 253846) +++ sys/dev/random/nehemiah.c (working copy) @@ -28,19 +28,20 @@ #include __FBSDID("$FreeBSD$"); -#include "opt_cpu.h" - -#ifdef PADLOCK_RNG - #include #include #include #include +#include #include #include +#include #include +#include +#include +#include #include #define RANDOM_BLOCK_SIZE 256 @@ -50,7 +51,7 @@ static void random_nehemiah_init(void); static void random_nehemiah_deinit(void); static int random_nehemiah_read(void *, int); -struct random_systat random_nehemiah = { +struct random_adaptor random_nehemiah = { .ident = "Hardware, VIA Nehemiah", .init = random_nehemiah_init, .deinit = random_nehemiah_deinit, @@ -208,4 +209,29 @@ random_nehemiah_read(void *buf, int c) return (c); } +static int +nehemiah_modevent(module_t mod, int type, void *unused) +{ + + switch (type) { + case MOD_LOAD: + if (via_feature_rng & VIA_HAS_RNG) { + random_adaptor_register("nehemiah", &random_nehemiah); + EVENTHANDLER_INVOKE(random_adaptor_attach, + &random_nehemiah); + return (0); + } else { +#ifndef KLD_MODULE + if (bootverbose) #endif + printf( + "%s: VIA RNG feature is not present on this CPU\n", + random_nehemiah.ident); + return (0); + } + } + + return (EINVAL); +} + +RANDOM_ADAPTOR_MODULE(nehemiah, nehemiah_modevent, 1); Index: sys/dev/random/probe.c =================================================================== --- sys/dev/random/probe.c (revision 253846) +++ sys/dev/random/probe.c (working copy) @@ -28,66 +28,35 @@ #include __FBSDID("$FreeBSD$"); -#if defined(__amd64__) || (defined(__i386__) && !defined(PC98)) +#if defined(__amd64__) || defined(__i386__) #include "opt_cpu.h" #endif -#include #include #include #include -#include -#include #include -#include - -#if defined(__amd64__) || (defined(__i386__) && !defined(PC98)) -#include -#include -#include -#include -#endif +#include #include -#include - -#if defined(__amd64__) || (defined(__i386__) && !defined(PC98)) -#ifdef PADLOCK_RNG -extern struct random_systat random_nehemiah; -#endif -#ifdef RDRAND_RNG -extern struct random_systat random_ivy; -#endif -#endif void -random_ident_hardware(struct random_systat **systat) +random_ident_hardware(struct random_adaptor **adaptor) { + struct random_adaptor *tmp; + int enable; - /* Set default to software */ - *systat = &random_yarrow; + /* Set default to software (yarrow) */ + *adaptor = random_adaptor_get("yarrow"); /* Then go looking for hardware */ -#if defined(__amd64__) || (defined(__i386__) && !defined(PC98)) -#ifdef PADLOCK_RNG - if (via_feature_rng & VIA_HAS_RNG) { - int enable; - - enable = 1; - TUNABLE_INT_FETCH("hw.nehemiah_rng_enable", &enable); - if (enable) - *systat = &random_nehemiah; - } -#endif -#ifdef RDRAND_RNG - if (cpu_feature2 & CPUID2_RDRAND) { - int enable; + enable = 1; + TUNABLE_INT_FETCH("hw.nehemiah_rng_enable", &enable); + if (enable && (tmp = random_adaptor_get("nehemiah"))) + *adaptor = tmp; - enable = 1; - TUNABLE_INT_FETCH("hw.ivy_rng_enable", &enable); - if (enable) - *systat = &random_ivy; - } -#endif -#endif + enable = 1; + TUNABLE_INT_FETCH("hw.ivy_rng_enable", &enable); + if (enable && (tmp = random_adaptor_get("rdrand"))) + *adaptor = tmp; } Index: sys/dev/random/random_adaptors.c =================================================================== --- sys/dev/random/random_adaptors.c (revision 0) +++ sys/dev/random/random_adaptors.c (working copy) @@ -0,0 +1,138 @@ +/*- + * Copyright (c) 2013 Arthur Mesh + * Copyright (c) 2013 David E. O'Brien + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer + * in this position and unchanged. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include + +LIST_HEAD(adaptors_head, random_adaptors); +static struct adaptors_head adaptors = LIST_HEAD_INITIALIZER(adaptors); +static struct sx adaptors_lock; /* need a sleepable lock */ + +/* List for the dynamic sysctls */ +static struct sysctl_ctx_list random_clist; + +MALLOC_DEFINE(M_RANDOM_ADAPTORS, "random_adaptors", "Random adaptors buffers"); + +int +random_adaptor_register(const char *name, struct random_adaptor *rsp) +{ + struct random_adaptors *rpp; + + KASSERT(name != NULL && rsp != NULL, ("invalid input to %s", __func__)); + + rpp = malloc(sizeof(struct random_adaptors), M_RANDOM_ADAPTORS, M_WAITOK); + rpp->name = name; + rpp->rsp = rsp; + + sx_xlock(&adaptors_lock); + LIST_INSERT_HEAD(&adaptors, rpp, entries); + sx_xunlock(&adaptors_lock); + + return (0); +} + +struct random_adaptor * +random_adaptor_get(const char *name) +{ + struct random_adaptors *rpp; + struct random_adaptor *rsp; + + rsp = NULL; + + sx_slock(&adaptors_lock); + + LIST_FOREACH(rpp, &adaptors, entries) + if (strcmp(rpp->name, name) == 0) + rsp = rpp->rsp; + + sx_sunlock(&adaptors_lock); + + return (rsp); +} + +static void +random_adaptors_deinit(void *unused) +{ + + sx_destroy(&adaptors_lock); + sysctl_ctx_free(&random_clist); +} + +static int +random_sysctl_adaptors_handler(SYSCTL_HANDLER_ARGS) +{ + struct random_adaptors *rpp; + int error; + + error = 0; + + sx_slock(&adaptors_lock); + + if (LIST_EMPTY(&adaptors)) + error = SYSCTL_OUT(req, "", strlen("")); + + LIST_FOREACH(rpp, &adaptors, entries) { + if (0 != SYSCTL_OUT(req, rpp->name, strlen(rpp->name))) + break; + } + + sx_sunlock(&adaptors_lock); + + return (error); +} + +static void +random_adaptors_init(void *unused) +{ + + SYSCTL_PROC(_kern_random, OID_AUTO, adaptors, + CTLTYPE_STRING | CTLFLAG_RD | CTLFLAG_MPSAFE, + NULL, 0, random_sysctl_adaptors_handler, "", + "Random Number Generator adaptors"); + + sx_init(&adaptors_lock, "random_adaptors"); +} + +SYSCTL_NODE(_kern, OID_AUTO, random, CTLFLAG_RW, 0, "Random Number Generator"); + +SYSINIT(random_adaptors, SI_SUB_DRIVERS, SI_ORDER_FIRST, random_adaptors_init, + NULL); +SYSUNINIT(random_adaptors, SI_SUB_DRIVERS, SI_ORDER_FIRST, + random_adaptors_deinit, NULL); Property changes on: sys/dev/random/random_adaptors.c ___________________________________________________________________ Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/dev/random/random_adaptors.h =================================================================== --- sys/dev/random/random_adaptors.h (revision 0) +++ sys/dev/random/random_adaptors.h (working copy) @@ -0,0 +1,66 @@ +/*- + * Copyright (c) 2013 Arthur Mesh + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer + * in this position and unchanged. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef __RANDOM_ADAPTORS_H__ +#define __RANDOM_ADAPTORS_H__ + +#include + +struct random_adaptors { + LIST_ENTRY(random_adaptors) entries; /* list of providers */ + const char *name; /* name of random adaptor */ + struct random_adaptor *rsp; +}; + +struct random_adaptor *random_adaptor_get(const char *); +int random_adaptor_register(const char *, struct random_adaptor *); + +/* + * random_adaptor's should be registered prior to + * random module (SI_SUB_DRIVERS/SI_ORDER_MIDDLE) + */ +#define RANDOM_ADAPTOR_MODULE(name, modevent, ver) \ + static moduledata_t name##_mod = { \ + #name, \ + modevent, \ + 0 \ + }; \ + DECLARE_MODULE(name, name##_mod, SI_SUB_DRIVERS, \ + SI_ORDER_SECOND); \ + MODULE_VERSION(name, ver); \ + MODULE_DEPEND(name, random, 1, 1, 1); + +typedef void (*random_adaptor_attach_hook)(void *, struct random_adaptor *); +EVENTHANDLER_DECLARE(random_adaptor_attach, random_adaptor_attach_hook); + +/* kern.random sysctls */ +#ifdef SYSCTL_DECL /* from sysctl.h */ +SYSCTL_DECL(_kern_random); +#endif /* SYSCTL_DECL */ + +#endif /* __RANDOM_ADAPTORS_H__ */ Property changes on: sys/dev/random/random_adaptors.h ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Index: sys/dev/random/randomdev.c =================================================================== --- sys/dev/random/randomdev.c (revision 253846) +++ sys/dev/random/randomdev.c (working copy) @@ -70,12 +70,15 @@ static struct cdevsw random_cdevsw = { .d_name = "random", }; -struct random_systat *random_systat; +static struct random_adaptor *random_adaptor; +static eventhandler_tag attach_tag; +static int random_inited; + /* For use with make_dev(9)/destroy_dev(9). */ static struct cdev *random_dev; -/* Used to fake out unused random calls in random_systat */ +/* Used to fake out unused random calls in random_adaptor */ void random_null_func(void) { @@ -88,8 +91,8 @@ random_close(struct cdev *dev __unused, { if ((flags & FWRITE) && (priv_check(td, PRIV_RANDOM_RESEED) == 0) && (securelevel_gt(td->td_ucred, 0) == 0)) { - (*random_systat->reseed)(); - random_systat->seeded = 1; + (*random_adaptor->reseed)(); + random_adaptor->seeded = 1; arc4rand(NULL, 0, 1); /* Reseed arc4random as well. */ } @@ -104,8 +107,8 @@ random_read(struct cdev *dev __unused, s void *random_buf; /* Blocking logic */ - if (!random_systat->seeded) - error = (*random_systat->block)(flag); + if (!random_adaptor->seeded) + error = (*random_adaptor->block)(flag); /* The actual read */ if (!error) { @@ -114,7 +117,7 @@ random_read(struct cdev *dev __unused, s while (uio->uio_resid > 0 && !error) { c = MIN(uio->uio_resid, PAGE_SIZE); - c = (*random_systat->read)(random_buf, c); + c = (*random_adaptor->read)(random_buf, c); error = uiomove(random_buf, c, uio); } @@ -139,7 +142,7 @@ random_write(struct cdev *dev __unused, error = uiomove(random_buf, c, uio); if (error) break; - (*random_systat->write)(random_buf, c); + (*random_adaptor->write)(random_buf, c); } free(random_buf, M_TEMP); @@ -172,14 +175,37 @@ random_poll(struct cdev *dev __unused, i int revents = 0; if (events & (POLLIN | POLLRDNORM)) { - if (random_systat->seeded) + if (random_adaptor->seeded) revents = events & (POLLIN | POLLRDNORM); else - revents = (*random_systat->poll) (events,td); + revents = (*random_adaptor->poll) (events,td); } return (revents); } +static void +random_initialize(void *p, struct random_adaptor *s) +{ + if (random_inited) { + printf("random: <%s> already initialized\n", + random_adaptor->ident); + return; + } + + random_adaptor = s; + + (s->init)(); + + printf("random: <%s> initialized\n", s->ident); + + random_dev = make_dev_credf(MAKEDEV_ETERNAL_KLD, &random_cdevsw, + RANDOM_MINOR, NULL, UID_ROOT, GID_WHEEL, 0666, "random"); + make_dev_alias(random_dev, "urandom"); /* XXX Deprecated */ + + /* mark random(4) as initialized, to avoid being called again */ + random_inited = 1; +} + /* ARGSUSED */ static int random_modevent(module_t mod __unused, int type, void *data __unused) @@ -188,23 +214,29 @@ random_modevent(module_t mod __unused, i switch (type) { case MOD_LOAD: - random_ident_hardware(&random_systat); - (*random_systat->init)(); - - if (bootverbose) - printf("random: \n", - random_systat->ident); + random_ident_hardware(&random_adaptor); - random_dev = make_dev_credf(MAKEDEV_ETERNAL_KLD, &random_cdevsw, - RANDOM_MINOR, NULL, UID_ROOT, GID_WHEEL, 0666, "random"); - make_dev_alias(random_dev, "urandom"); /* XXX Deprecated */ + if (random_adaptor == NULL) { + printf( + "random: No random adaptor attached, postponing initialization\n"); + attach_tag = EVENTHANDLER_REGISTER(random_adaptor_attach, + random_initialize, NULL, EVENTHANDLER_PRI_ANY); + } else { + random_initialize(NULL, random_adaptor); + } break; case MOD_UNLOAD: - (*random_systat->deinit)(); - - destroy_dev(random_dev); + if (random_adaptor != NULL) { + (*random_adaptor->deinit)(); + destroy_dev(random_dev); + } + /* Unregister the event handler */ + if (attach_tag != NULL) { + EVENTHANDLER_DEREGISTER(random_adaptor_attach, + attach_tag); + } break; Index: sys/dev/random/randomdev.h =================================================================== --- sys/dev/random/randomdev.h (revision 253846) +++ sys/dev/random/randomdev.h (working copy) @@ -38,7 +38,7 @@ typedef void random_write_func_t(void *, typedef int random_poll_func_t(int, struct thread *); typedef void random_reseed_func_t(void); -struct random_systat { +struct random_adaptor { struct selinfo rsel; const char *ident; int seeded; @@ -51,7 +51,5 @@ struct random_systat { random_reseed_func_t *reseed; }; -extern struct random_systat *random_systat; - -extern void random_ident_hardware(struct random_systat **); +extern void random_ident_hardware(struct random_adaptor **); extern void random_null_func(void); Index: sys/dev/random/randomdev_soft.c =================================================================== --- sys/dev/random/randomdev_soft.c (revision 253846) +++ sys/dev/random/randomdev_soft.c (working copy) @@ -38,6 +38,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include #include @@ -50,6 +51,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include @@ -63,7 +65,7 @@ static int random_yarrow_poll(int event, static int random_yarrow_block(int flag); static void random_yarrow_flush_reseed(void); -struct random_systat random_yarrow = { +struct random_adaptor random_yarrow = { .ident = "Software, Yarrow", .init = random_yarrow_init, .deinit = random_yarrow_deinit, @@ -103,7 +105,7 @@ static int random_kthread_control = 0; static struct proc *random_kthread_proc; /* List for the dynamic sysctls */ -struct sysctl_ctx_list random_clist; +static struct sysctl_ctx_list random_clist; /* ARGSUSED */ static int @@ -120,25 +122,20 @@ random_yarrow_init(void) { int error, i; struct harvest *np; - struct sysctl_oid *random_o, *random_sys_o, *random_sys_harvest_o; + struct sysctl_oid *random_sys_o, *random_sys_harvest_o; enum esource e; - random_o = SYSCTL_ADD_NODE(&random_clist, - SYSCTL_STATIC_CHILDREN(_kern), - OID_AUTO, "random", CTLFLAG_RW, 0, - "Software Random Number Generator"); - - random_yarrow_init_alg(&random_clist, random_o); + random_yarrow_init_alg(&random_clist); random_sys_o = SYSCTL_ADD_NODE(&random_clist, - SYSCTL_CHILDREN(random_o), + SYSCTL_STATIC_CHILDREN(_kern_random), OID_AUTO, "sys", CTLFLAG_RW, 0, "Entropy Device Parameters"); SYSCTL_ADD_PROC(&random_clist, SYSCTL_CHILDREN(random_sys_o), OID_AUTO, "seeded", CTLTYPE_INT | CTLFLAG_RW, - &random_systat->seeded, 1, random_check_boolean, "I", + &random_yarrow.seeded, 1, random_check_boolean, "I", "Seeded State"); random_sys_harvest_o = SYSCTL_ADD_NODE(&random_clist, @@ -362,10 +359,10 @@ random_yarrow_write(void *buf, int count void random_yarrow_unblock(void) { - if (!random_systat->seeded) { - random_systat->seeded = 1; - selwakeuppri(&random_systat->rsel, PUSER); - wakeup(random_systat); + if (!random_yarrow.seeded) { + random_yarrow.seeded = 1; + selwakeuppri(&random_yarrow.rsel, PUSER); + wakeup(&random_yarrow); } (void)atomic_cmpset_int(&arc4rand_iniseed_state, ARC4_ENTR_NONE, ARC4_ENTR_HAVE); @@ -377,10 +374,10 @@ random_yarrow_poll(int events, struct th int revents = 0; mtx_lock(&random_reseed_mtx); - if (random_systat->seeded) + if (random_yarrow.seeded) revents = events & (POLLIN | POLLRDNORM); else - selrecord(td, &random_systat->rsel); + selrecord(td, &random_yarrow.rsel); mtx_unlock(&random_reseed_mtx); return revents; @@ -394,12 +391,12 @@ random_yarrow_block(int flag) mtx_lock(&random_reseed_mtx); /* Blocking logic */ - while (!random_systat->seeded && !error) { + while (!random_yarrow.seeded && !error) { if (flag & O_NONBLOCK) error = EWOULDBLOCK; else { printf("Entropy device is blocking.\n"); - error = msleep(random_systat, + error = msleep(&random_yarrow, &random_reseed_mtx, PUSER | PCATCH, "block", 0); } @@ -420,3 +417,30 @@ random_yarrow_flush_reseed(void) random_yarrow_reseed(); } + +static int +yarrow_modevent(module_t mod, int type, void *unused) +{ + + switch (type) { + case MOD_LOAD: + random_adaptor_register("yarrow", &random_yarrow); + /* + * For statically built kernels that contain both random.ko and + * *_rng.ko, this event handler will do nothing, since + * random.ko is loaded after *_rng.ko's, and hence hasn't yet + * registered for this event. + * + * In case where both random.ko and *_rng.ko are built as + * modules, random.ko is loaded prior to *_rng.ko's (by + * dependency). This event handler is there to delay creation + * of /dev/{u,}random and attachment of this *_rng.ko. + */ + EVENTHANDLER_INVOKE(random_adaptor_attach, &random_yarrow); + return (0); + } + + return (EINVAL); +} + +RANDOM_ADAPTOR_MODULE(yarrow, yarrow_modevent, 1); Index: sys/dev/random/randomdev_soft.h =================================================================== --- sys/dev/random/randomdev_soft.h (revision 253846) +++ sys/dev/random/randomdev_soft.h (working copy) @@ -72,10 +72,10 @@ void random_process_event(struct harvest void random_yarrow_reseed(void); void random_yarrow_unblock(void); -void random_yarrow_init_alg(struct sysctl_ctx_list *, struct sysctl_oid *); +void random_yarrow_init_alg(struct sysctl_ctx_list *); void random_yarrow_deinit_alg(void); -extern struct random_systat random_yarrow; +extern struct random_adaptor random_yarrow; extern struct mtx random_reseed_mtx; /* If this was c++, this would be a template */ Index: sys/dev/random/yarrow.c =================================================================== --- sys/dev/random/yarrow.c (revision 253846) +++ sys/dev/random/yarrow.c (working copy) @@ -41,6 +41,7 @@ __FBSDID("$FreeBSD$"); #include #include +#include #include #include @@ -101,7 +102,7 @@ random_process_event(struct harvest *eve } void -random_yarrow_init_alg(struct sysctl_ctx_list *clist, struct sysctl_oid *in_o) +random_yarrow_init_alg(struct sysctl_ctx_list *clist) { int i; struct sysctl_oid *random_yarrow_o; @@ -110,7 +111,7 @@ random_yarrow_init_alg(struct sysctl_ctx * have a very good clue about what they do! */ random_yarrow_o = SYSCTL_ADD_NODE(clist, - SYSCTL_CHILDREN(in_o), + SYSCTL_STATIC_CHILDREN(_kern_random), OID_AUTO, "yarrow", CTLFLAG_RW, 0, "Yarrow Parameters"); Index: tools/tools/sysdoc/tunables.mdoc =================================================================== --- tools/tools/sysdoc/tunables.mdoc (revision 253845) +++ tools/tools/sysdoc/tunables.mdoc (working copy) @@ -1093,6 +1093,13 @@ line programs. kern.quantum --- +kern.random.adaptors +str + +Displays registered PRNG adaptors. +This is a read-only variable. + +--- kern.random.sys.burst --- From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 21:57:24 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C11FA258 for ; Thu, 8 Aug 2013 21:57:24 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 21BB1262E for ; Thu, 8 Aug 2013 21:57:23 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r78LvJ1B093968; Fri, 9 Aug 2013 00:57:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r78LvJ1B093968 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r78LvJrm093967; Fri, 9 Aug 2013 00:57:19 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 9 Aug 2013 00:57:19 +0300 From: Konstantin Belousov To: Masao Uebayashi Subject: Re: panic(9) vs. RB_NOSYNC Message-ID: <20130808215719.GP4972@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u/BH/w+/n8IGbYqX" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:57:24 -0000 --u/BH/w+/n8IGbYqX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 08, 2013 at 02:36:51PM +0900, Masao Uebayashi wrote: > panic(9) (actually vpanic()) sets RB_NOSYNC when panicstr is already > set. What is the reasoning of this? >=20 > My understanding is that panic() attempts VFS "sync" operation at > first. If another panic() is triggered during that, give up VFS > "sync". Is this correct? If so, how reliable is this design? I > wonder if attempting such a complex task like VFS "sync" after a panic > is a good idea. Look at the end of the vpanic(), right before kern_reboot() call. There, kernel does if (!sync_on_panic) bootopt |=3D RB_NOSYNC; so it only syncs when sync_on_panic sysctl is set to non-zero, which is zero by default. Basically, this option might be reasonable when you debug something not related to i/o+VM+storage drivers, and you know what you do. --u/BH/w+/n8IGbYqX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJSBBQ+AAoJEJDCuSvBvK1Bo2wP/1npprp+pVPGSxJ7BjPg8Cbk rZcHoJryghaPaZ0TL+u639bEdweTtt5eAZAdLt1FkUmDiQhHj01EDTIwwc8kc4Kw NDMQHOCNwS6Qg5e8OAK7GfkYwJcECsaAlDozWYS7AmnnZRKaey49crFpLJIaIHd+ EFi3zbg8V/2+x1oUghSdi+nuo6Dm8IinByEnnIqQfJ77Cj6QwQA5aaUkj6RryqkV iHb9Ti/i11pMseczszbCi7LIzD/LQdXVHPQHRUevdJylxFzA079XMQ3vRXcOlhmc +sK7oa42+98eyAZQIoFNsa+MYVumyScydD+OBdKl0NIvqOrVRWhilyArrOm/W6tm GsYt0QjD3/KKIH6R/syMLIjEL9cKerzdwSe/c37VzyC4e2d909qFDyMRnZNEuvEN mkaX5o5Ba+bnSphTVx/Ed5T/ZV57+xvhHOYL5HUEcdgm+3vFzJX9csGYyfvzvS0z I9I29DeYv9dt2TX0q7qV34WI/1dxQzpqueoNzVyX26Wy7BA/wxhjgPqHiXvpUx76 bJVnwpg8n2T3i9vmBd6OVLeMtF0/excjhITb1qayW28O996ThecOXfm53rfMMDza KHLrqv4fgnNeQ6xHfH+9lII5mr39lo7C6KKhP+gznCxV9ZFm6XTOvcS11xPn3Irt 7c0DoH2//fB7xX6SQCWI =BA8V -----END PGP SIGNATURE----- --u/BH/w+/n8IGbYqX-- From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 21:58:40 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CB5C530B; Thu, 8 Aug 2013 21:58:40 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8A1A4263A; Thu, 8 Aug 2013 21:58:40 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.7/8.14.7) with ESMTP id r78LwYhr001774; Thu, 8 Aug 2013 14:58:34 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.7/8.14.7/Submit) id r78LwYib001773; Thu, 8 Aug 2013 14:58:34 -0700 (PDT) (envelope-from sgk) Date: Thu, 8 Aug 2013 14:58:34 -0700 From: Steve Kargl To: obrien@freebsd.org, secteam@freebsd.org, freebsd-arch@freebsd.org, Arthur Mesh Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130808215834.GA1732@troutmask.apl.washington.edu> References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <20130808213449.GD95000@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130808213449.GD95000@dragon.NUXI.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:58:40 -0000 On Thu, Aug 08, 2013 at 02:34:49PM -0700, David O'Brien wrote: > On Wed, Aug 07, 2013 at 12:27:36PM -0700, Steve Kargl wrote: > > On Wed, Aug 07, 2013 at 11:28:58AM -0700, David O'Brien wrote: > > > * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" > > > option. The files sha2.c, hash.c, randomdev_soft.c and yarrow.c > .. > > My kernel config files have included the following 2 lines for > > ages: > > makeoptions NO_MODULES > > device random > > > > If I try to build a new kernel under your scheme, will the > > build die with an error about a missing option? > > You haven't given enough information to answer the question. Your kernel > config does not have just those two lines. Is there an "include GENERIC" > or something else above it? What is your full kernel config? No 'include GENERIC'. See config file after sig. > > > If the answer > > is 'no', then the yarrow adaptor should be opt-out. > > There is no build issue (i.e., missing symbols). "device random" in the > changeset is just the device (/dev/[u]random) implimentation. The many > RNG's that provide the output. The issue is quite simple. If I do not use modules and only include 'device random' in my config file, will this result in a crippled/broken/non-functioning /dev/random? > Do you really not read UPDATING and the release notes when you upgrade to > to a .0 release? How did you learn about other config lines I'm sure > you've changed over th years. I never see a .0 release as I only run -current. I scan UPDATING when I see a chnage has been made to it via svn-src-all. I missed your change to UPDATING because a broken procmail rule filtered that particular commit. I note that I don't update my systems every 24 hours. There is sometimes a 2 or 3 month lag between a full upgrade, so I may forget that someone potential change a kernel option or broke a kernel facility. In this case, inveriably 'make buildkernel' kernel dies a horrible death. -- Steve cpu HAMMER ident HPC makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols makeoptions NO_MODULES maxusers 0 options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption options INET # InterNETworking options INET6 # IPv6 communications protocols options SCTP # Stream Transmission Control Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options NFSCL # New Network Filesystem Client options NFSD # New Network Filesystem Server options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options FDESCFS options PSEUDOFS # Pseudo-filesystem framework options COMPAT_LINUX32 options LINPROCFS options COMPAT_43TTY # BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD32 # Compatible with i386 binaries options COMPAT_FREEBSD7 # Compatible with i386 binaries options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options P1003_1B_SEMAPHORES options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # Default partitioning schemes options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # Bus support. device acpi device pci # Floppy drives options FDC_DEBUG device fdc # New CAM ATA and ATAPI devices device ata device ahci device mvs device siis # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # SCSI peripherals device scbus # SCSI bus (required for SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) device ses # SCSI Environmental Services (and SAF-TE) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard #device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets device drm # DRM core module required by DRM drivers device mach64drm # ATI Rage Pro, Rage Mobility P/M, Rage XL # Serial (COM) ports device uart # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device ppi # Parallel port interface device # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device bge # Broadcom BCM570xx Gigabit Ethernet device fxp # Pseudo devices. device loop # Network loopback device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device usb # USB Bus (required) device uhid # "Human Interface Devices" device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse options MAXDSIZ=(8UL*1024UL*1024*1024) options MAXSSIZ=(1024UL*1024*1024) options DFLDSIZ=(1024UL*1024*1024) # This allows you to actually store this configuration file into # the kernel binary itself, where it may be later read by saying: # strings -n 3 /boot/kernel/kernel | sed -n 's/^___//p' > MYKERNEL # options INCLUDE_CONFIG_FILE # Include this file in kernel # # Don't enter the debugger for a panic. Intended for unattended operation # where you may want to enter the debugger from the console, but still want # the machine to recover from a panic. # options KDB_UNATTENDED # Size of the kernel message buffer. Should be N * pagesize. options MSGBUF_SIZE=81920 device blank_saver options MAXCONS=8 # number of virtual consoles device amdtemp # Temperature sensors. device smbus # Bus support, required for smb below. device amdsmb device smb # device iicbus # Bus support, required for ic/iic/iicsmb below. device iicbb device ic device iic device iicsmb # smb over i2c bridge device hwpmc # Driver (also a loadable module) options HWPMC_HOOKS # Other necessary kernel hooks From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 21:59:00 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5C7E83C4; Thu, 8 Aug 2013 21:59:00 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DDCA02641; Thu, 8 Aug 2013 21:58:59 +0000 (UTC) Received: from mail18-db8-R.bigfish.com (10.174.8.237) by DB8EHSOBE003.bigfish.com (10.174.4.66) with Microsoft SMTP Server id 14.1.225.22; Thu, 8 Aug 2013 21:58:57 +0000 Received: from mail18-db8 (localhost [127.0.0.1]) by mail18-db8-R.bigfish.com (Postfix) with ESMTP id 42341AE010E; Thu, 8 Aug 2013 21:58:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.54; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zz1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzzz2fh2a8h668h839hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1155h) Received-SPF: pass (mail18-db8: domain of juniper.net designates 66.129.224.54 as permitted sender) client-ip=66.129.224.54; envelope-from=sjg@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail18-db8 (localhost.localdomain [127.0.0.1]) by mail18-db8 (MessageSwitch) id 1375999135471142_24322; Thu, 8 Aug 2013 21:58:55 +0000 (UTC) Received: from DB8EHSMHS023.bigfish.com (unknown [10.174.8.236]) by mail18-db8.bigfish.com (Postfix) with ESMTP id 6E27E600048; Thu, 8 Aug 2013 21:58:55 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.54) by DB8EHSMHS023.bigfish.com (10.174.4.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 8 Aug 2013 21:58:54 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 8 Aug 2013 14:58:53 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r78LwrL05523; Thu, 8 Aug 2013 14:58:53 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 2288458097; Thu, 8 Aug 2013 14:58:53 -0700 (PDT) To: Mark R V Murray Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion In-Reply-To: <94E41175-EF09-47D1-9661-9AF04E8FA9A0@grondar.org> References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <5203968D.7060508@freebsd.org> <7018AAA9-0A88-430F-96B7-867E5F529B36@bsdimp.com> <50BE6942-CC39-413C-8E14-C6B93440901B@grondar.org> <20130808211657.GC95000@dragon.NUXI.org> <94E41175-EF09-47D1-9661-9AF04E8FA9A0@grondar.org> Comments: In-reply-to: Mark R V Murray message dated "Thu, 08 Aug 2013 22:19:46 +0100." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Thu, 8 Aug 2013 14:58:53 -0700 Message-ID: <20130808215853.2288458097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Arthur Mesh , secteam@freebsd.org, Steve Kargl , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 21:59:00 -0000 >> Our approach is mechanism over policy. That is, give the user the >> choice of if their HW should be used directly or fed into the SW PRNG. > >I don't see a problem with that either, as long as there are no nasty >surprises like the possibility of getting no RNG at all, and not being >in a position to notice. If there are bread crumbs to show whether an RNG is present or not in the output from config, it should be feasible to fail the build which as others have noted would be a "good thing"[TM] vs producing a toxic kernel. From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 22:09:16 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2AB6993F for ; Thu, 8 Aug 2013 22:09:16 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D9D4026D3 for ; Thu, 8 Aug 2013 22:09:15 +0000 (UTC) Received: by mail-vc0-f169.google.com with SMTP id ib11so536624vcb.28 for ; Thu, 08 Aug 2013 15:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cJDMcNq2ZLThIZJq71CmBFS9LiaOQfULNwYOjaI/SYU=; b=04yd0Gr6pvYl6knkWDXUuRHKuixDdZ1SuH5UOkASjcXHiCrFNtB/goii+qPYNsMZwI +/npA8FigTHJbaVkEysfDcWUeawDm7XrVcPDpk13XrJUp6JIWO6Rrw7X44MaqTNy+cGU FTeO1XKx8u1+mQNtC8NlJ5HQ4YPi9k8vTIdZ4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cJDMcNq2ZLThIZJq71CmBFS9LiaOQfULNwYOjaI/SYU=; b=PGtHSGNQJi6Jv/tDqThTbNZ9mrKPYvIPjomzBnK11jHJZSUCISk5CsPv6u3NEQbgpg jIsXxg1oWkcfLta9TXsNXc19XIVXtUsVTTb/lPHPxZuBgzisvn4UHMrGwvh4cKzqpybm RdfKZvotSh/lXTLIAzKt+Qy+uGDOZtbcgJJRt3NwXhuQS2RKhMuXeuLZhcFm6u4kEWFi 3o9KoU4Y6wpjuoCqolXteW60P/KGS/I7UfKLj0mU5MELLC7SCS8enycNcvHcu7LtBJRz GRzhU73QaQkXQ/CfpUBlhkSPIj2yOaoxrLTm44WR5soJQ0pcEjVZKM/odN11zhFpLB38 srIw== X-Gm-Message-State: ALoCoQnidgE6H++36N8HTCKY+WZF3S1A2lnOTuZ5H/YP6NcxfqigezXOY2QF0/xjQ/jRN1Z3NKG7 MIME-Version: 1.0 X-Received: by 10.52.22.4 with SMTP id z4mr3638828vde.115.1375999754950; Thu, 08 Aug 2013 15:09:14 -0700 (PDT) Received: by 10.220.167.74 with HTTP; Thu, 8 Aug 2013 15:09:14 -0700 (PDT) In-Reply-To: <201308081023.53040.jhb@freebsd.org> References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <201308081023.53040.jhb@freebsd.org> Date: Thu, 8 Aug 2013 15:09:14 -0700 Message-ID: Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion From: Peter Wemm To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: Arthur Mesh , secteam@freebsd.org, Steve Kargl , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 22:09:16 -0000 On Thu, Aug 8, 2013 at 7:23 AM, John Baldwin wrote: > On Wednesday, August 07, 2013 4:20:29 pm Peter Wemm wrote: [..] > The counter to this is that in the recent past, any suggestion to add anything > to DEFAULTS was met with "that's the wrong way". In actual fact, changes > to GENERIC happen quite often, and we often break older kernel configs from > older branches (ATA_CAM is no longer in 10 for example). I'm not sure I buy > the argument that we can never break kernel configs from older branches. I was talking about changes that break configs without detection. ATA_CAM is different. If the kernel fails to configure or compile, you fix it and repeat. The original patch meant your working kernel config built/installed without the slightest hint that something was wrong until it was a brick after boot. That's what I was taking issue with. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV UTF-8: for when a ' just won\342\200\231t do. ZFS must be the bacon of file systems. "everything's better with ZFS" From owner-freebsd-arch@FreeBSD.ORG Thu Aug 8 23:17:21 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8D829B6A; Thu, 8 Aug 2013 23:17:21 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail107.syd.optusnet.com.au (mail107.syd.optusnet.com.au [211.29.132.53]) by mx1.freebsd.org (Postfix) with ESMTP id 3806C2A43; Thu, 8 Aug 2013 23:17:21 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail107.syd.optusnet.com.au (Postfix) with ESMTPS id A972CD448D7; Fri, 9 Aug 2013 09:17:15 +1000 (EST) Date: Fri, 9 Aug 2013 09:17:13 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Mark R V Murray Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion In-Reply-To: <50BE6942-CC39-413C-8E14-C6B93440901B@grondar.org> Message-ID: <20130809081923.N1044@besplex.bde.org> References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <5203968D.7060508@freebsd.org> <7018AAA9-0A88-430F-96B7-867E5F529B36@bsdimp.com> <50BE6942-CC39-413C-8E14-C6B93440901B@grondar.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=DstvpgP+ c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=zRGD7RnwAEsA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=wdFzHWp-jKkA:10 a=AeKwieAPptnafv6lJtYA:9 a=CjuIK1q_8ugA:10 Cc: Arthur Mesh , Steve Kargl , secteam@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 23:17:21 -0000 On Thu, 8 Aug 2013, Mark R V Murray wrote: > I still want to get back something like the original get_cyclecount(); simple and quick. I don't care what its called, but out doesn't need to be the massive thing that the current get_cyclecount() has grown to be on x86. rdtsc(), I think it was. The simple and quick version cannot exist, and never did. The original i386 version was: 1.50 (markm 21-Nov-00): /* 1.50 (markm 21-Nov-00): * Return contents of in-cpu fast counter as a sort of "bogo-time" 1.50 (markm 21-Nov-00): * for non-critical timing. 1.50 (markm 21-Nov-00): */ 1.50 (markm 21-Nov-00): static __inline u_int64_t 1.50 (markm 21-Nov-00): get_cyclecount(void) 1.50 (markm 21-Nov-00): { 1.50 (markm 21-Nov-00): #if defined(I386_CPU) || defined(I486_CPU) 1.50 (markm 21-Nov-00): struct timespec tv; 1.50 (markm 21-Nov-00): 1.50 (markm 21-Nov-00): if ((cpu_feature & CPUID_TSC) == 0) { 1.50 (markm 21-Nov-00): nanotime(&tv); 1.50 (markm 21-Nov-00): return (tv.tv_sec * (u_int64_t)1000000000 + tv.tv_nsec); 1.50 (markm 21-Nov-00): } 1.50 (markm 21-Nov-00): #endif 1.50 (markm 21-Nov-00): return (rdtsc()); 1.50 (markm 21-Nov-00): } This is not so simple, and is unquick if there is no TSC. If I386_CPU or I486_CPU is configured, then it is suboptimal even if there is a TSC. Other arches are even further from always having a TSC. The simple and quvck version would always return 0 or a kernel global like time.tv_nsec if there is no TSC and no other readable freqently changing timer or noise source that can be read almost as fast as memory. It wouldn't guarantee any entropy. The current version is only slightly unsimpler and unquicker: - on amd64, it is still just inline rdtsc() On other versions, the nanotime() in it was first improved to binuptime(). This also gave more noise in the extra low bits, and mixing of the bits made it less abusable as a timer. The latter has been broken on some arches. - on arm, the bits are still mixed by ((sec << 56) | (frac >> 8)) (8 bits of sec and 56 bits of frac. I don't like losing some low bits (it is better to xor things), but the result is fairly unusable as a timer and perhaps there is nothing useful in the low bits on arm (it takes a very high frequency clock like a TSC and/or delicate ntpd adjustments that aren't very noisy to put anything there). The 8-bit seconds count isn't too good when KTR abuses get_cyclecount.(). - on i386, read_cycleount() is still inline, but the inline just calls the function pointer cpu_tick(). If there is a TSC, then cpu_tick points to an un-inline rdtsc() and the result is a slightly pessimzed version of the above if I386_CPU or I486_CPU is configured and a more pessimized version of the above if neither is configured. Otherwise, the result is the accumulated tick count of the currently active timecounter. This is much better for noise in get_cyclecount() and much worse for its primary purpose of timing than is binuptime() with bits mixed to form a timer. The active timecounter can change, and then the frequency and offset of its ticker changes. Its primary use is for process times, and there is some recalibration for this, but this is incomplete and buggy. But for get_cyclecount(), the noise is a feature. The noise from this is bad when KTR abuses get_cyclecount(). Otherwise, this is better for get_cyclecount() than the old binuptime() method. - on ia64, get_cyclecount is #define'd as another function. The declaration and definition of the other function are even more obscure. They are generated by a macro. Standard namespace pollution in sys/systm.h is depended on to join the definitions. - mips is like ia64 except the obfuscation chain is shorter. provides its own namespace pollution, so sys/systm.h and its pollution aren't depended on... - on powerpc, get_cyclecount() reads a counter using inline asm. It spells the 2 32-bit components of the counter as essentially time._upper and time._lower, so it isn't clear if they are actually times to begin with. - sparc64 uses inline asm to read some register which is hopefully a counter. So, get_cyclecount() is actually simple and quick (except for macros hiding the simplicity) on all arches except arm and old i386. But it is very MD, so it takes a lot of code with different simplicity to support it for all arches. Still better than #ifdefing it wherever it is used. Bruce From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 01:24:10 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BCDCD6A0 for ; Fri, 9 Aug 2013 01:24:10 +0000 (UTC) (envelope-from uebayasi@gmail.com) Received: from mail-bk0-x22a.google.com (mail-bk0-x22a.google.com [IPv6:2a00:1450:4008:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 501712189 for ; Fri, 9 Aug 2013 01:24:10 +0000 (UTC) Received: by mail-bk0-f42.google.com with SMTP id my10so919152bkb.29 for ; Thu, 08 Aug 2013 18:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W/XvGXj9RxpaLwXSEqsJ8c3Hnt/TT8QKSKUFRfTgV7M=; b=OTxze4w0unAC68o1DXiT+pzRYhWxl+5d/sPa6v52TqAR+Hw10ZK4I8IaTGWZZhjHgg ARJSypUD72O/XhPVKxA8E4aEujZ8ZTQOmBWbi8jU5tSdLwro6RKV+ofo6IyBAT1fgrfy zrXMA+wVp87gGJTxC3EdBm6Vomz7c/njosumKpmtjFPx7apaZJmG0C8qW5i4WC/iGi1r 3K9/i+qbvRXJI+2WFc6qGAHCCocrojSh5FivZ3vlMksnCYRE6MQCEo3KZ3pcUL/4Vx7i CYoKw8aQFX62ibB9hHcEih9ruq8pLYy0Xrh4cmVtsri3Or1F8+NJDm1957csmDAcuTYg y6hg== MIME-Version: 1.0 X-Received: by 10.204.103.5 with SMTP id i5mr1815128bko.176.1376011448492; Thu, 08 Aug 2013 18:24:08 -0700 (PDT) Received: by 10.205.36.9 with HTTP; Thu, 8 Aug 2013 18:24:08 -0700 (PDT) In-Reply-To: <20130808215719.GP4972@kib.kiev.ua> References: <20130808215719.GP4972@kib.kiev.ua> Date: Fri, 9 Aug 2013 10:24:08 +0900 Message-ID: Subject: Re: panic(9) vs. RB_NOSYNC From: Masao Uebayashi To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 01:24:10 -0000 On Fri, Aug 9, 2013 at 6:57 AM, Konstantin Belousov wrote: > On Thu, Aug 08, 2013 at 02:36:51PM +0900, Masao Uebayashi wrote: >> panic(9) (actually vpanic()) sets RB_NOSYNC when panicstr is already >> set. What is the reasoning of this? >> >> My understanding is that panic() attempts VFS "sync" operation at >> first. If another panic() is triggered during that, give up VFS >> "sync". Is this correct? If so, how reliable is this design? I >> wonder if attempting such a complex task like VFS "sync" after a panic >> is a good idea. > > Look at the end of the vpanic(), right before kern_reboot() call. > There, kernel does > if (!sync_on_panic) > bootopt |= RB_NOSYNC; > so it only syncs when sync_on_panic sysctl is set to non-zero, which > is zero by default. I didn't notice that. > Basically, this option might be reasonable when you debug something > not related to i/o+VM+storage drivers, and you know what you do. So most of FreeBSD users have been happy without try-sync-after-panic for years. Good to know that, thanks! From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 01:33:50 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 51284AED; Fri, 9 Aug 2013 01:33:50 +0000 (UTC) (envelope-from obrien@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 332FE2228; Fri, 9 Aug 2013 01:33:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r791XoeO037111; Fri, 9 Aug 2013 01:33:50 GMT (envelope-from obrien@freefall.freebsd.org) Received: (from obrien@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r791XmCe037108; Fri, 9 Aug 2013 01:33:48 GMT (envelope-from obrien) Date: Thu, 8 Aug 2013 18:33:46 -0700 From: "David O'Brien" To: "Simon J. Gerraty" Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130809013346.GG95000@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, "Simon J. Gerraty" , Mark R V Murray , Arthur Mesh , Steve Kargl , secteam@freebsd.org, freebsd-arch@freebsd.org References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <5203968D.7060508@freebsd.org> <7018AAA9-0A88-430F-96B7-867E5F529B36@bsdimp.com> <50BE6942-CC39-413C-8E14-C6B93440901B@grondar.org> <20130808211657.GC95000@dragon.NUXI.org> <94E41175-EF09-47D1-9661-9AF04E8FA9A0@grondar.org> <20130808215853.2288458097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130808215853.2288458097@chaos.jnpr.net> X-Operating-System: FreeBSD 10.0-CURRENT X-MUA-Host: dragon.NUXI.org X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Arthur Mesh , secteam@freebsd.org, Steve Kargl , Mark R V Murray , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 01:33:50 -0000 On Thu, Aug 08, 2013 at 02:58:53PM -0700, Simon Gerraty wrote: > If there are bread crumbs to show whether an RNG is present or not in > the output from config, it should be feasible to fail the build > which as others have noted would be a "good thing"[TM] vs producing a > toxic kernel. I may have misunderstood what you're saying. But if not, you're not allowing for one using .ko's to have this functionality. How do I fail the build if I want to have 'device random' but use some external provided RNG thru a kernel module? The original changeset supported that. Or for what ever reason I want to have the choice of RNG left up to which base kernel module I load? 'sysctl kern.random.adaptors' showing an empty list does provide a bread crumb. /etc/rc.d/initrandom could certainly check this value and complain loudly. -- -- David (obrien@FreeBSD.org) From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 03:01:46 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D77DACD4; Fri, 9 Aug 2013 03:01:46 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (gw.catspoiler.org [75.1.14.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A30752790; Fri, 9 Aug 2013 03:01:46 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id r7931XDc059355; Thu, 8 Aug 2013 20:01:37 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201308090301.r7931XDc059355@gw.catspoiler.org> Date: Thu, 8 Aug 2013 20:01:33 -0700 (PDT) From: Don Lewis Subject: Re: Reliable process tracking To: julian@FreeBSD.org In-Reply-To: <5203FA18.20403@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 03:01:46 -0000 On 9 Aug, Julian Elischer wrote: > I've been pondering the possibility of appending a universe (jail) > number to the > UIDS, PIDS and various other things. (classes maybe?). > > It wouldn't have to be everywhere, but ther eare a number of places > where comparisons would > DTRT if they were comparing "my_jail+my_uid" with "his_jail+his_uid", > instead of just the UIDs. > It would also help with the "multiple roots" problem, and might > simplify some of the current code. If that's all you want, then why not just compare proc1->p_fd->fd_jdir to proc2->p_fd->fd_jdir for the jail check? From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 03:05:55 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 57426E86; Fri, 9 Aug 2013 03:05:55 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EFBFB27D5; Fri, 9 Aug 2013 03:05:54 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r7935mS4093315 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 8 Aug 2013 20:05:50 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <52045C87.2080203@freebsd.org> Date: Fri, 09 Aug 2013 11:05:43 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Don Lewis Subject: Re: Reliable process tracking References: <201308090301.r7931XDc059355@gw.catspoiler.org> In-Reply-To: <201308090301.r7931XDc059355@gw.catspoiler.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 03:05:55 -0000 On 8/9/13 11:01 AM, Don Lewis wrote: > On 9 Aug, Julian Elischer wrote: > >> I've been pondering the possibility of appending a universe (jail) >> number to the >> UIDS, PIDS and various other things. (classes maybe?). >> >> It wouldn't have to be everywhere, but ther eare a number of places >> where comparisons would >> DTRT if they were comparing "my_jail+my_uid" with "his_jail+his_uid", >> instead of just the UIDs. >> It would also help with the "multiple roots" problem, and might >> simplify some of the current code. > If that's all you want, then why not just compare > proc1->p_fd->fd_jdir to proc2->p_fd->fd_jdir > for the jail check? > > > because multiple jails can have the same root directory? there are other tests one can do too, if one is willing to do multiple tests everywhere. From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 06:41:23 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0A8C9F6A; Fri, 9 Aug 2013 06:41:23 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A9B5D2161; Fri, 9 Aug 2013 06:41:22 +0000 (UTC) Received: from mail11-ch1-R.bigfish.com (10.43.68.236) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Fri, 9 Aug 2013 06:26:06 +0000 Received: from mail11-ch1 (localhost [127.0.0.1]) by mail11-ch1-R.bigfish.com (Postfix) with ESMTP id 89281340271; Fri, 9 Aug 2013 06:26:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.51; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 3 X-BigFish: VPS3(zzzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzzz2fh2a8h668h839hd25hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1155h) Received-SPF: pass (mail11-ch1: domain of juniper.net designates 66.129.224.51 as permitted sender) client-ip=66.129.224.51; envelope-from=sjg@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail11-ch1 (localhost.localdomain [127.0.0.1]) by mail11-ch1 (MessageSwitch) id 1376029565139452_11367; Fri, 9 Aug 2013 06:26:05 +0000 (UTC) Received: from CH1EHSMHS035.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.234]) by mail11-ch1.bigfish.com (Postfix) with ESMTP id 1C41A1C0047; Fri, 9 Aug 2013 06:26:05 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.51) by CH1EHSMHS035.bigfish.com (10.43.70.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 9 Aug 2013 06:26:05 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Thu, 8 Aug 2013 23:26:03 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r796Q3L22631; Thu, 8 Aug 2013 23:26:03 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 2053E58097; Thu, 8 Aug 2013 23:26:03 -0700 (PDT) To: , Mark R V Murray , Arthur Mesh , Steve Kargl , , Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion In-Reply-To: <20130809013346.GG95000@dragon.NUXI.org> References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <5203968D.7060508@freebsd.org> <7018AAA9-0A88-430F-96B7-867E5F529B36@bsdimp.com> <50BE6942-CC39-413C-8E14-C6B93440901B@grondar.org> <20130808211657.GC95000@dragon.NUXI.org> <94E41175-EF09-47D1-9661-9AF04E8FA9A0@grondar.org> <20130808215853.2288458097@chaos.jnpr.net> <20130809013346.GG95000@dragon.NUXI.org> Comments: In-reply-to: "David O'Brien" message dated "Thu, 08 Aug 2013 18:33:46 -0700." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Thu, 8 Aug 2013 23:26:03 -0700 Message-ID: <20130809062603.2053E58097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 06:41:23 -0000 On Thu, 8 Aug 2013 18:33:46 -0700, "David O'Brien" writes: >I may have misunderstood what you're saying. But if not, you're >not allowing for one using .ko's to have this functionality. I'm simply saying that if you can arrange for a build failure instead of producing a toxic system, it becomes much simpler to assure folk that you cannot do them harm with these changes. If you can't then it might be wise to leave a default like yarrow in place, that can be used as a fallback if no (or until) suitable .ko's are loaded? >'sysctl kern.random.adaptors' showing an empty list does provide >a bread crumb. /etc/rc.d/initrandom could certainly check this >value and complain loudly. That's probably a bit too late though isn't it. From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 06:47:28 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0227FF3 for ; Fri, 9 Aug 2013 06:47:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BED6F2185 for ; Fri, 9 Aug 2013 06:47:27 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id x14so3618420ief.12 for ; Thu, 08 Aug 2013 23:47:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=kF+xHmaiUJDKC9j+cRf0bnz7+2xoYwphw2nKLfJVL4E=; b=iyNrEdFHAiNEuOsFakY+YeUhRqsWvARIljfmARpE4s5W6Zo9v5tGsBPBMesTQMzga2 3qeNHNB1nh5VPZYezZnxS0Kh+cuOkeValaxHQfLeqmNN2vQmg1+Nqjpei9N5euTQolQa GxpAGTUtDsq4x0e68S7g3410yIhKMKAOaw0bFIW503pwz3mMkx3ek/PVvXDWawZTE4W2 zpyXaZkXZX+r0c7bPWPCNS/eOiUEECUvnz8zC6FmAjqhvG5ptfLH2OfshbfBk65hoVXf EXFnmHeCcFPr3CRaeaQe6VS1Ow5zG2UMB2RosquFaDgEn6ZUxORDeo37D+vgLt2vgEvG h9tg== X-Gm-Message-State: ALoCoQn3t5uNdYu1Dtw3WmmORqg9yfau2OA6OqgMOrNNTFkEEevjGOwXFf+m+NcI8jS96YlH0aZ3 X-Received: by 10.43.149.137 with SMTP id kk9mr3806017icc.109.1376030846564; Thu, 08 Aug 2013 23:47:26 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id r6sm2205661igp.8.2013.08.08.23.47.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 23:47:25 -0700 (PDT) Sender: Warner Losh Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130809013346.GG95000@dragon.NUXI.org> Date: Fri, 9 Aug 2013 00:47:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <5203968D.7060508@freebsd.org> <7018AAA9-0A88-430F-96B7-867E5F529B36@bsdimp.com> <50BE6942-CC39-413C-8E14-C6B93440901B@grondar.org> <20130808211657.GC95000@dragon.NUXI.org> <94E41175-EF09-47D1-9661-9AF04E8FA9A0@grondar.org> <20130808215853.2288458097@chaos.jnpr.net> <20130809013346.GG95000@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1085) Cc: Arthur Mesh , Steve Kargl , "Simon J. Gerraty" , secteam@freebsd.org, Mark R V Murray , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 06:47:28 -0000 On Aug 8, 2013, at 7:33 PM, David O'Brien wrote: > On Thu, Aug 08, 2013 at 02:58:53PM -0700, Simon Gerraty wrote: >> If there are bread crumbs to show whether an RNG is present or not in >> the output from config, it should be feasible to fail the build >> which as others have noted would be a "good thing"[TM] vs producing a >> toxic kernel. >=20 > I may have misunderstood what you're saying. But if not, you're > not allowing for one using .ko's to have this functionality. >=20 > How do I fail the build if I want to have 'device random' but use > some external provided RNG thru a kernel module? The original > changeset supported that. Or for what ever reason I want to have > the choice of RNG left up to which base kernel module I load? I still don't understand why Yarrow can't be the default, fallback = mechanism that gets overridden when a new module is loaded. Rather than = arguing this point, perhaps you could work to make that possible? That = would allow you to implement things with hardware png, while still = providing a sane fallback until such time that those can be loaded,,, > 'sysctl kern.random.adaptors' showing an empty list does provide > a bread crumb. /etc/rc.d/initrandom could certainly check this > value and complain loudly. The poison has been drunk at this time, it is too late to back out = gracefully. Warner From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 06:57:59 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BA3F347E for ; Fri, 9 Aug 2013 06:57:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 876BF21EC for ; Fri, 9 Aug 2013 06:57:59 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id s9so3615088iec.34 for ; Thu, 08 Aug 2013 23:57:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=4N7QxnD3KMQzIxavbAv37R9SebSwax5N0xF6u8hDyWI=; b=n7iVUnVwE/7E1hWsGVBcb7zK/VJ2IJQU3IqatT5vuT5m6ApMoUS/2l5l16M33EGDO0 mjzIV5CWZ4A8GpmihHc+gVr/LoGH1Dyu1XzjxEbWu0kTFtInC7VqEnkM9HZ/3bvjx7j9 21i2wwuxLJMnen2YyFEgUYcbdP4skINfCGzOEMZ9/13L9/cXJ6iiRw0xfWOsJYA7nfw/ Y+Fh9o0U7CduDf1t5yP2HuN9wSYRDHD8mZAlU+xERrZ3worwi4TOI0sTuOiroqQgHVVb 4ZAmTWHOWSuNlYer08d6oTGv7SPCnWTo0OIsGJt4pjmXqa3C/qDlxo3HJwJvALV0wjPd HT8A== X-Gm-Message-State: ALoCoQkLp8IUmuMj4aglt3I6uqjwmerO80gJNCiSxLOsOccn/FGWbn3zMWkevz/UbTUwJMb+IiMO X-Received: by 10.50.88.7 with SMTP id bc7mr1369387igb.37.1376031473613; Thu, 08 Aug 2013 23:57:53 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ht10sm2271001igb.2.2013.08.08.23.57.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 23:57:52 -0700 (PDT) Sender: Warner Losh Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130808211517.GB95000@dragon.NUXI.org> Date: Fri, 9 Aug 2013 00:57:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3E657C33-CA0D-4CDB-8CCD-72BCCC43B085@bsdimp.com> References: <20130807182858.GA79286@dragon.NUXI.org> <223174A5-A146-4969-A3CF-6923EF7ECCF2@bsdimp.com> <20130808211517.GB95000@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1085) Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 06:57:59 -0000 On Aug 8, 2013, at 3:15 PM, David O'Brien wrote: > On Thu, Aug 08, 2013 at 01:20:19PM -0600, Warner Losh wrote: >> The sheer number of config files you changed says this is a bad idea, >> or you are during something very wrong. >=20 > Why? That's the sheer number of config files that have "device = random" > in them. How it reasonable for "device random" to be in them but not > random(4) options? For the most part, those are wrong too. > We did not like having to change so many config files -- the ARM = kernel > configs seems to be in need of additional refactoring. You need to use the mechanisms that are already present in the arm = kernel config files to accomplish this. You are doing it the wrong way, = and I'm telling you the right way. Don't argue, just fix it then. You = yourself just admitted you don't like the way you chose, why are you = arguing with me about this? >> Also, you bogusly changed way too many config files rather than the >> underlying std.* files for the ARM port. >=20 > If that is the case, why isn't "device random" in the std.* files? Because that was slavishly, and bogusly, copied from GENERIC on other = architectures. > Please address that before saying that random(4) options should live > somewhere else than where "device random" lives. No. I'm telling you the proper place to put your changes. This isn't = about making a perfect system, only how you can help to get there. I = won't be drawn into the perfect system argument. >> What's wrong with having yarrow as the default, fallback mechanism. = And >> why do you have a design that seems to force one, and only one, into >> the kernel? The way it is now we fail bad rather than fail to yarrow >> fallback. This seems unwise. >=20 > How does it force 1 and only 1 into the kernel? If there were some > MIPS or ARM HW they would also be in the kernel. When markm@ = completes > his Fortuna work, it could (and likely would) also live beside Yarrow. > Or a NIST SP 800-90-A compliant HMAC_DRBG can also live in the kernel > beside Yarrow (and Fortuna). Obviously at the point of having more > than one SW PRNG we'll have a selection mechanism to "break ties". > Right now the code only handles that for HW. Forcing one and only one into the kernel is wrong. You are approaching = the problem wrong if that's a requirement. That's like saying you can = have one and only one time keeping thing compiled into the kernel. You = can have several, but only use one. It is use that's important here, not = the number that are compiled in. Only one can be in use at any given = time, true. Have a design that enforces that, not that there can be only = one compiled into or loaded into the kernel at a time. This would allow = a fail-safe mechanism, as well as the knobs to disable it, rather than a = fail stupid mechanism you've proposed. >> I haven't read the code in detail, but I don't see how I'd override >> the CPU's random number unit with one from a plug-in board when it is >> present. >=20 > Please read the code to see how that is handled in > sys/dev/random/probe.c:random_ident_hardware(). Note that my commit = did > not change the logic here (just updated the implementation of it). = It's > the same logic we've had since 2004 (r128059 and updated in = 2012(r240135)). If you can override it, then I fail to see why the fallback is so hard? Warner From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 07:29:25 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id E37E7B4C; Fri, 9 Aug 2013 07:29:25 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A761F2374; Fri, 9 Aug 2013 07:29:25 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V7h8U-0000CN-A7; Fri, 09 Aug 2013 08:29:23 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5212E8EA-BC8C-41B3-ACF0-637431FC740A"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <20130808214033.GE95000@dragon.NUXI.org> Date: Fri, 9 Aug 2013 08:29:10 +0100 Message-Id: <71489715-FB89-48CA-8DD6-88AEEA996EA9@grondar.org> References: <20130807183516.GC79319@dragon.NUXI.org> <1EDB5C8E-5755-4A8A-89F1-A64412080744@yahoo.com> <20130808205514.GA95000@dragon.NUXI.org> <1F5C260F-DA73-4D71-BB4B-E749BA9DEB57@grondar.org> <20130808214033.GE95000@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: Arthur Mesh , Scott Long , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 07:29:26 -0000 --Apple-Mail=_5212E8EA-BC8C-41B3-ACF0-637431FC740A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 8 Aug 2013, at 22:40, David O'Brien wrote: > On Thu, Aug 08, 2013 at 10:22:42PM +0100, Mark R V Murray wrote: >> Mechanism exists, but its disabled. I'd like to re-enable it. Look = for >> "seeded =3D 1" in randomdev_soft.c, and see what that "seeded" = variable >> does. >=20 > Hi Mark, > I'm not sure what you're saying here. That we could block at boot for > reason of the PRGN not being seeded if desired? Correct! > Or that we start seeded and thus never get unseeded? That is what we currently do. We "fix" it by pumping junk into = /dev/random with initrandom, but this is racey and suboptimal. M --=20 Mark R V Murray --Apple-Mail=_5212E8EA-BC8C-41B3-ACF0-637431FC740A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUgSaUd58vKOKE6LNAQpP+wP+M9oIujCWbyHzOu5xL0cnybRsZBSXZnBC URVYFpnb+rfQU2C+h5tD+1p+PSBGhaZGtLel6ewssh1/3hvdphUuckgBNIrzJ+q5 pltL2lXrr87dd1GPdfoiUZYzR4zgUamU97sIamRG34PqixaUjArADfsutvZYce6k ALAL5oG8oGA= =0Gsa -----END PGP SIGNATURE----- --Apple-Mail=_5212E8EA-BC8C-41B3-ACF0-637431FC740A-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 07:46:25 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id DC6D0204 for ; Fri, 9 Aug 2013 07:46:24 +0000 (UTC) (envelope-from fabient@freebsd.org) Received: from work.netasq.com (gwlille.netasq.com [91.212.116.1]) by mx1.freebsd.org (Postfix) with ESMTP id 7612F2445 for ; Fri, 9 Aug 2013 07:46:23 +0000 (UTC) Received: from work.netasq.com (localhost [127.0.0.1]) by work.netasq.com (Postfix) with ESMTP id 234AF2706321; Fri, 9 Aug 2013 09:46:17 +0200 (CEST) Received: from [10.2.1.1] (unknown [91.212.116.2]) by work.netasq.com (Postfix) with ESMTPSA id EB5AA2706092; Fri, 9 Aug 2013 09:46:16 +0200 (CEST) Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Apple Message framework v1283) From: Fabien Thomas In-Reply-To: <50BE6942-CC39-413C-8E14-C6B93440901B@grondar.org> Date: Fri, 9 Aug 2013 09:46:16 +0200 Message-Id: References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <5203968D.7060508@freebsd.org> <7018AAA9-0A88-430F-96B7-867E5F529B36@bsdimp.com> <50BE6942-CC39-413C-8E14-C6B93440901B@grondar.org> To: Mark R V Murray X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 07:46:25 -0000 >>=20 >> On Aug 8, 2013, at 7:01 AM, Andrey Chernov wrote: >>=20 >>> Many years ago I already suggest to de-modularize random (making it = not >>> optional), with fallback to yarrow if hardware RNGs can't be probed = or >>> not configured. >>=20 >> I think that the 'fallback to yarrow' is necessary here. >=20 > My current inclination is to make Yarrow the basic device (or "Fortuna = Lite", but that is a problem for MUCH later), and make the hardware = devices feed Yarrow, if they are present. I also think this is the best option to have as a default: - Keep a good software random - Add more source of entropy at early boot - Dont trust HW random (keep it as one probed source of seed) User can choose to switch to pure HW random to replace SW. A good source of information here: = http://th.informatik.uni-mannheim.de/people/lucks/papers/Ferguson/Fortuna.= pdf Fabien= From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 08:42:13 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id EFFB1A3D for ; Fri, 9 Aug 2013 08:42:13 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F0802807 for ; Fri, 9 Aug 2013 08:42:13 +0000 (UTC) Received: by mail-bk0-f51.google.com with SMTP id mx10so989019bkb.24 for ; Fri, 09 Aug 2013 01:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n91e8CX/CjNZEue773T0CTAhowSHzAihiMDFYtbRX7o=; b=A1CghO8g8V6M77ULTRlTj5366XBO2KCgaq+w+64gAzdoS2A5byKuTZVigLF7zH796z Z4bkFcqRLeT7/ThyM7Izjx94FICazcjxOylzE48bH5F5V+AHu5A2sIgxCg5oCuqw9d/d gT1yQrvJi6BBai9m5+mEJgiqoWTtdtH5nrTS0Z7bzsNahVtU11mNS1vzJqhFZiZo3rBF u+3DCE0hdbCFon5aiQMQYkS/2t6pBzLNQj1XxuiNkpbN2asezkAGX0Q+AEuMO1oW8rUi JqVDFqOZQiguETMJvnVSc1MyyiQS0gvmNtfm6nNnmEIKi1vBkoJO9LBMqWgei3wRhZdW HLQg== X-Received: by 10.205.24.6 with SMTP id rc6mr2046632bkb.66.1376037731541; Fri, 09 Aug 2013 01:42:11 -0700 (PDT) Received: from [192.168.1.4] (ajg99.neoplus.adsl.tpnet.pl. [83.25.240.99]) by mx.google.com with ESMTPSA id od6sm3230312bkb.11.2013.08.09.01.42.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 01:42:11 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Reliable process tracking From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <20130807201934.GA4918@stack.nl> Date: Fri, 9 Aug 2013 10:42:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <87717220-8094-49BE-BF04-010D9788ABD3@FreeBSD.org> References: <20130804134658.GC35080@stack.nl> <20130807201934.GA4918@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1508) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 08:42:14 -0000 Wiadomo=B6=E6 napisana przez Jilles Tjoelker w dniu 7 = sie 2013, o godz. 22:19: > On Mon, Aug 05, 2013 at 01:13:10PM +0200, Edward Tomasz Napiera=B3a = wrote: >> Wiadomo=B6=E6 napisana przez Jilles Tjoelker w dniu = 4 sie 2013, o godz. 15:46: >>> When shutting down a service or requesting status, rc.subr currently >>> uses a combination of pidfiles and process names. This is fairly but = not >>> completely reliable once it is set up correctly (which can take a = lot of >>> work and possibly patching the daemon to use pidfile(3) from our >>> libutil). It is also incapable of killing multiprocess daemons such = as >>> CGI web servers without cooperation of the daemon. >=20 >>> I think what is needed here is a facility that marks a process and = all >>> of its descendants. Removing the mark should be a privileged or at = least >>> an unusual operation; no unprivileged function specified by POSIX = such >>> as setsid() should do this. >=20 >> I've actually thought about that when I added setloginclass(2). It's >> trivial to modify rc.subr to use su(8) to set login class for each >> service. It should be trivial to modify pkill(1) and killall(1) to >> add "-c" option to kill all processes in a given login class. >=20 > There are some problems with su -c: >=20 > * It refuses to set a login class name that is not in /etc/login.conf. > Given that multiple instances of a service should each have their own > kernel login class, it may make sense to allow specifying the > login.conf entry separate from the kernel login class. Indeed. I'll try to figure out something. FWIW, I've just committed a patch that adds "-c" flag to pkill. [..] From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 09:59:59 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 995BFA85; Fri, 9 Aug 2013 09:59:59 +0000 (UTC) (envelope-from oshogbo.vx@gmail.com) Received: from mail-bk0-x22f.google.com (mail-bk0-x22f.google.com [IPv6:2a00:1450:4008:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DCE262BAD; Fri, 9 Aug 2013 09:59:58 +0000 (UTC) Received: by mail-bk0-f47.google.com with SMTP id mx12so1005779bkb.34 for ; Fri, 09 Aug 2013 02:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :content-type; bh=z2QS8AdY/0vJRM0zOFbJ29tKd3zAyEEfy6mrt8+bzBM=; b=jGSMUfpnFM1EQGU2ARe6YlaIX5CFpEcUQqSwXilLng0k90AOTdv/V/J6rpkXJ99AW+ 7XBOW5ZUYzRgQAJhwT8YqNlY/L7WSzA8brVY84BA39sEu/tHBHv5dCtk+7Yu1RkhrbZp nVI+IE1NHACM5cORu+nYPd/HeK4YBAdmnMhruh0brp55DLpb6JgmvdpX4PIJV8BH15x+ g/cUSEWPHyxICpEpdhvxoPCbFXDrKXtI/qbOGaCUCS2PIYbKu7d+1rS/IEugU+w/KBg2 seP9RVUa3rnKmRc2lOY5xEdqRMEXLwVHG2jpr+oibn4Xl3k7r8a0Jr3qjsk3TTUR809/ glOQ== X-Received: by 10.205.9.8 with SMTP id ou8mr2136143bkb.76.1376042396949; Fri, 09 Aug 2013 02:59:56 -0700 (PDT) Received: from [192.168.0.195] (58.wheelsystems.com. [83.12.187.58]) by mx.google.com with ESMTPSA id et15sm3296800bkc.0.2013.08.09.02.59.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 09 Aug 2013 02:59:55 -0700 (PDT) Sender: Mario Oshogbo Message-ID: <5204BD94.7050800@FreeBSD.org> Date: Fri, 09 Aug 2013 11:59:48 +0200 From: Mario Oshogbo User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: closedir - change in the libc X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KjmkLWTW566TBTRP5Q5VAkAlRDJmGKQq1" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 09:59:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KjmkLWTW566TBTRP5Q5VAkAlRDJmGKQq1 Content-Type: multipart/mixed; boundary="------------070702080808080009040308" This is a multi-part message in MIME format. --------------070702080808080009040308 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I'm a student attending in GSoC'13 in project "Write new features for Capsicum" [1] and I would like to propose a little change to the libc. In the libc we have the function opendir(3) and fdopendir(3) which are responsible for opening directories. We also have function closedir(3) which is responsible for free the structure allocated by two previous funcions. The problem with the closedir(3) is that he close fd used as argument of fdopendir(3). I think programmer should be able to make a choice if he want to close this descriptor automatically or not. Of course we are able to use for dup(2) function and save fd before calling fdopendir(3) to prevent closing but I think this is the one syscall which we could sav= e. To support the propose I would like to give some example. I working now on making the fts(3) more sandbox friendly which means I would like to remove all fchdir(2) functions and operate only on fd. One of the steps I perform is changing the opendir(3) to the fdopendir(3). I also must remember the fd of currently opened directory after perform fclosedir. If we have N of directories we must perform N additional dup(2) and N additional close(2) functions to save this fd. So I would like to propose function called fdclosedir which will free DIR structure but will not close fd attached to DIR structure. This function also could return this fd which make it useful with the opendir(3) function, when we don't know the fd but we would like free DIR structure and perform some operations only on fd. I attach diff file with my proposal of change. Chears, oshogbo [1] https://wiki.freebsd.org/SummerOfCode2013/CapsicumFeatures --------------070702080808080009040308 Content-Type: text/x-patch; name="fdclosedir.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="fdclosedir.patch" --- lib/libc/gen/closedir.c 2013-08-07 11:20:34.000000000 +0200 +++ lib/libc/gen/closedir.c 2013-08-07 11:21:09.000000000 +0200 @@ -49,7 +49,7 @@ * close a directory. */ int -closedir(DIR *dirp) +fdclosedir(DIR *dirp) { int fd; =20 @@ -65,5 +65,12 @@ _pthread_mutex_destroy(&dirp->dd_lock); } free((void *)dirp); - return(_close(fd)); + return (fd); +} + +int +closedir(DIR *dirp) +{ + + return (_close(fdclosedir(dirp))); } --- lib/libc/gen/directory.3 2013-08-07 11:21:48.000000000 +0200 +++ lib/libc/gen/directory.3 2013-08-07 11:25:20.000000000 +0200 @@ -40,6 +40,7 @@ .Nm seekdir , .Nm rewinddir , .Nm closedir , +.Nm fdclosedir , .Nm dirfd .Nd directory operations .Sh LIBRARY @@ -64,6 +65,8 @@ .Ft int .Fn closedir "DIR *dirp" .Ft int +.Fn fdclosedir "DIR *dirp" +.Ft int .Fn dirfd "DIR *dirp" .Sh DESCRIPTION The @@ -208,6 +211,14 @@ is set to indicate the error. .Pp The +.Fn fdclosedir +function +is equivalent to the +.Fn closedir +function except that this function returns directory file descriptor +instead of closing it. +.Pp +The .Fn dirfd function returns the integer file descriptor associated with the named @@ -252,6 +263,9 @@ .Fn fdopendir function appeared in .Fx 8.0 . +.Fn fdclosedir +function appeared in +.Fx 10.0 . .Sh BUGS The invalidation of .Fn telldir --- include/dirent.h 2013-08-07 11:19:41.000000000 +0200 +++ include/dirent.h 2013-08-07 11:19:10.000000000 +0200 @@ -79,6 +79,7 @@ #endif #if __BSD_VISIBLE DIR *__opendir2(const char *, int); +int fdclosedir(DIR *); int getdents(int, char *, int); int getdirentries(int, char *, int, long *); #endif --------------070702080808080009040308-- --KjmkLWTW566TBTRP5Q5VAkAlRDJmGKQq1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJSBL2ZAAoJECRkYejLhN/ji6gP/RR3PLfrS7hdq6cFMbIcsBDV 0F2ZDZDQKMK2iAgSotDh5vP4MyMDSN9170zpn6TtCBB+HD/5JAufOr0bEmDh6Rqh /PuAzkif1O/a/fiZ659FfLkKa9YDmY9lNhvzliPI9ZGWwx5RBA2fqfdVn6rpFpZT 39LnZqfqBcdQUijfzdOM0XPBp0FbiHyHnrK6LzkfdpMWFmZT1OA0XLMAEWudRcbD lm59K+8ZGib9MF2DcH+sQ4Oebb+BtLYdwxCU27Bt6gQ8JEzSgsCzGW9XJSfkpE0F NXiINUAUCaqE9RtXAEl9VMcXvgBYtzaV9No3ZWpmF+BuEe4fS/Mzmg9vWoLT/em7 cGvAnXbA/47hgEnxAQlmZ61lw7giroU1mqMaHU2c7fFwC8nCEyHUiLoixFZmPb5u ILwn8YVtNfyCj+5fiEkwRzFJRKjaQW80u8O2umQabp0axNcE+C05kH7Tzvzxvb7m hyjAAOgBxzsxWIGMYPAsca2hBU+9/3n74l16DzgeEjdNRB3yaWSWOB4sa9y/X6V0 Afyp9z/cDZRBJVV2ONW42+YeqyMpsAp7SjSg+C+TsDDFFrjghE2ImiXFOIm2E/fT ePPV+OPpedaJPUB5yx11SUGEqLyYAs+jnTQMSMD/ont8CuXDMDj8HosMid2XnCfV rJHgrAUyWE1W49gwPGCT =dnQh -----END PGP SIGNATURE----- --KjmkLWTW566TBTRP5Q5VAkAlRDJmGKQq1-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 10:59:37 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C6C0FB71; Fri, 9 Aug 2013 10:59:37 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 86A9D2FF1; Fri, 9 Aug 2013 10:59:37 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 001A13592DA; Fri, 9 Aug 2013 12:59:34 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id DB00628494; Fri, 9 Aug 2013 12:59:34 +0200 (CEST) Date: Fri, 9 Aug 2013 12:59:34 +0200 From: Jilles Tjoelker To: Mario Oshogbo Subject: Re: closedir - change in the libc Message-ID: <20130809105934.GA32419@stack.nl> References: <5204BD94.7050800@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5204BD94.7050800@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 10:59:37 -0000 On Fri, Aug 09, 2013 at 11:59:48AM +0200, Mario Oshogbo wrote: > I'm a student attending in GSoC'13 in project "Write new features for > Capsicum" [1] and I would like to propose a little change to the libc. > In the libc we have the function opendir(3) and fdopendir(3) which are > responsible for opening directories. We also have function closedir(3) > which is responsible for free the structure allocated by two previous > funcions. > The problem with the closedir(3) is that he close fd used as argument of > fdopendir(3). I think programmer should be able to make a choice if he > want to close this descriptor automatically or not. Of course we are > able to use for dup(2) function and save fd before calling fdopendir(3) > to prevent closing but I think this is the one syscall which we could save. > To support the propose I would like to give some example. I working now > on making the fts(3) more sandbox friendly which means I would like to > remove all fchdir(2) functions and operate only on fd. One of the steps > I perform is changing the opendir(3) to the fdopendir(3). I also must > remember the fd of currently opened directory after perform fclosedir. > If we have N of directories we must perform N additional dup(2) and N > additional close(2) functions to save this fd. > So I would like to propose function called fdclosedir which will free > DIR structure but will not close fd attached to DIR structure. This > function also could return this fd which make it useful with the > opendir(3) function, when we don't know the fd but we would like free > DIR structure and perform some operations only on fd. I attach diff file > with my proposal of change. While this looks sensible, the only advantage is cleaner code and less memory usage. Instead of additional dup()/close(), you could also keep the DIR around as long as you need the fd. The ugliest part is that you may also have regular open()s on directories (for example if the maximum number of file descriptors had been exceeded and some directories had to be closed and now need to be reopened). I think this should remain doable, though. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 15:02:05 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8D3F646E; Fri, 9 Aug 2013 15:02:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 66EF02D37; Fri, 9 Aug 2013 15:02:05 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 50A35B979; Fri, 9 Aug 2013 11:02:04 -0400 (EDT) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Reliable process tracking Date: Fri, 9 Aug 2013 11:00:01 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p28; KDE/4.5.5; amd64; ; ) References: <201308090301.r7931XDc059355@gw.catspoiler.org> <52045C87.2080203@freebsd.org> In-Reply-To: <52045C87.2080203@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201308091100.02052.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 09 Aug 2013 11:02:04 -0400 (EDT) Cc: Don Lewis X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 15:02:05 -0000 On Thursday, August 08, 2013 11:05:43 pm Julian Elischer wrote: > On 8/9/13 11:01 AM, Don Lewis wrote: > > On 9 Aug, Julian Elischer wrote: > > > >> I've been pondering the possibility of appending a universe (jail) > >> number to the > >> UIDS, PIDS and various other things. (classes maybe?). > >> > >> It wouldn't have to be everywhere, but ther eare a number of places > >> where comparisons would > >> DTRT if they were comparing "my_jail+my_uid" with "his_jail+his_uid", > >> instead of just the UIDs. > >> It would also help with the "multiple roots" problem, and might > >> simplify some of the current code. > > If that's all you want, then why not just compare > > proc1->p_fd->fd_jdir to proc2->p_fd->fd_jdir > > for the jail check? > > > > > > > because multiple jails can have the same root directory? However, td1->td_ucred->cr_prison == td2->td_ucred->cr_prison would work. OTOH, there are folks looking at considering how to make other types of security tokens work that is needed for better integration with other systems (think remote Windows AD logins or remote Kerberos realms). If you want to pursue this path you should likely talk to Robert Watson, Justin Gibbs, and other folks that they suggest. I think their route is probably a better model for uids/gids. I do think it might make sense to have per-jail namespaces for other things like pids, login classes, etc. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 17:38:25 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 8CBC8E33; Fri, 9 Aug 2013 17:38:25 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 50DBA2633; Fri, 9 Aug 2013 17:38:25 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=[192.168.42.211]) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1V7qdq-00018L-Ee; Fri, 09 Aug 2013 18:38:23 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_66292627-6D00-450B-86C0-5B09D574B328"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: Date: Fri, 9 Aug 2013 18:38:33 +0100 Message-Id: <3B3D9F96-DF69-4B53-B6AE-C9C39BDDC8D7@grondar.org> References: <20130807182858.GA79286@dragon.NUXI.org> <20130807192736.GA7099@troutmask.apl.washington.edu> <5203968D.7060508@freebsd.org> <7018AAA9-0A88-430F-96B7-867E5F529B36@bsdimp.com> <50BE6942-CC39-413C-8E14-C6B93440901B@grondar.org> To: Fabien Thomas X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 17:38:25 -0000 --Apple-Mail=_66292627-6D00-450B-86C0-5B09D574B328 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 9 Aug 2013, at 08:46, Fabien Thomas wrote: > I also think this is the best option to have as a default: > > - Keep a good software random > - Add more source of entropy at early boot > - Dont trust HW random (keep it as one probed source of seed) > > User can choose to switch to pure HW random to replace SW. I like! :-) M -- Mark R V Murray --Apple-Mail=_66292627-6D00-450B-86C0-5B09D574B328 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUgUpGd58vKOKE6LNAQrZfQP/RvRJjdxgKOstXyckT+Tqrw3mrFsNdxPz ofAcMQ1f9Zm3+Zmd98zxVogFg3uHppdC85qxwyVpTLwbv5VdeZa+O2EXNsCjxA2O c2uwb4IvyDglf1Br0JFwgnQbIlY1JQ+wWRdBuHT3rBNf45m/81qCo6p1JE61ieqJ p0J1/bzsEj4= =UN7K -----END PGP SIGNATURE----- --Apple-Mail=_66292627-6D00-450B-86C0-5B09D574B328-- From owner-freebsd-arch@FreeBSD.ORG Sat Aug 10 10:30:51 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 13DEDBBC; Sat, 10 Aug 2013 10:30:51 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CBD3E242A; Sat, 10 Aug 2013 10:30:50 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 2F0A91203CA; Sat, 10 Aug 2013 12:30:37 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 0710728494; Sat, 10 Aug 2013 12:30:37 +0200 (CEST) Date: Sat, 10 Aug 2013 12:30:36 +0200 From: Jilles Tjoelker To: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= Subject: Re: Reliable process tracking Message-ID: <20130810103036.GA40636@stack.nl> References: <20130804134658.GC35080@stack.nl> <20130807201934.GA4918@stack.nl> <87717220-8094-49BE-BF04-010D9788ABD3@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87717220-8094-49BE-BF04-010D9788ABD3@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 10:30:51 -0000 On Fri, Aug 09, 2013 at 10:42:09AM +0200, Edward Tomasz Napierała wrote: > Wiadomość napisana przez Jilles Tjoelker w dniu 7 sie 2013, o godz. 22:19: > > On Mon, Aug 05, 2013 at 01:13:10PM +0200, Edward Tomasz Napierała wrote: > >> Wiadomość napisana przez Jilles Tjoelker w dniu 4 sie 2013, o godz. 15:46: > >>> When shutting down a service or requesting status, rc.subr currently > >>> uses a combination of pidfiles and process names. This is fairly but not > >>> completely reliable once it is set up correctly (which can take a lot of > >>> work and possibly patching the daemon to use pidfile(3) from our > >>> libutil). It is also incapable of killing multiprocess daemons such as > >>> CGI web servers without cooperation of the daemon. > >>> I think what is needed here is a facility that marks a process and all > >>> of its descendants. Removing the mark should be a privileged or at least > >>> an unusual operation; no unprivileged function specified by POSIX such > >>> as setsid() should do this. > >> I've actually thought about that when I added setloginclass(2). It's > >> trivial to modify rc.subr to use su(8) to set login class for each > >> service. It should be trivial to modify pkill(1) and killall(1) to > >> add "-c" option to kill all processes in a given login class. > > There are some problems with su -c: > > * It refuses to set a login class name that is not in /etc/login.conf. > > Given that multiple instances of a service should each have their own > > kernel login class, it may make sense to allow specifying the > > login.conf entry separate from the kernel login class. > Indeed. I'll try to figure out something. > FWIW, I've just committed a patch that adds "-c" flag to pkill. On another note, init(8) does not set the kernel login class for /etc/rc to daemon as might be expected from the /etc/login.conf entry used. I use this patch: Index: sbin/init/init.c =================================================================== --- sbin/init/init.c (revision 253911) +++ sbin/init/init.c (working copy) @@ -1729,7 +1729,8 @@ login_cap_t *lc; if ((lc = login_getclassbyname(cname, NULL)) != NULL) { setusercontext(lc, (struct passwd*)NULL, 0, - LOGIN_SETPRIORITY | LOGIN_SETRESOURCES); + LOGIN_SETPRIORITY | LOGIN_SETRESOURCES | + LOGIN_SETLOGINCLASS); login_close(lc); } } Should I commit this? -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Sat Aug 10 15:12:53 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9006319A for ; Sat, 10 Aug 2013 15:12:53 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 238F9217C for ; Sat, 10 Aug 2013 15:12:52 +0000 (UTC) Received: by mail-bk0-f52.google.com with SMTP id e11so1705285bkh.11 for ; Sat, 10 Aug 2013 08:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MlBZnj+yPDDJooDI3gfdxo/NttGXrkRgWlLtpiW289M=; b=RglV5LXe6bB5rakLzi2SuzDU+tMgyVBbtmKFAQokbDdMfHquGh5JAxCmtdroL+qMLp UzPL0HhSOVxRLu3h9kKl6Uq0yz/eg1E/QynWHDmvdWt9s1tLKw5yjPsXLBds9S4d1Ie9 DqVW1A3apPVMSJuVz6act1mDEyp9q6mU+IQfI33jZxje54vfxdfCg853Flg1vZ1KBvd8 CwDKiF3qmtqQWdTZ/A06IpqWgiP2Auc2vjb1hkThvb98KJ8SJSrIfjGFYt55tpioSVT7 a/vluFwobpMQ6NGZCJIJ1MDi5dlC8T1G567fvswpJjP/5DOc2qWyYBYT0XPKlgtQ9k9/ p3kA== X-Received: by 10.204.176.75 with SMTP id bd11mr2745714bkb.62.1376147570473; Sat, 10 Aug 2013 08:12:50 -0700 (PDT) Received: from [192.168.1.4] (addq65.neoplus.adsl.tpnet.pl. [79.184.68.65]) by mx.google.com with ESMTPSA id ct12sm4110268bkb.12.2013.08.10.08.12.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 10 Aug 2013 08:12:50 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Content-Type: text/plain; charset=iso-8859-2 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Subject: Re: Reliable process tracking From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <20130810103036.GA40636@stack.nl> Date: Sat, 10 Aug 2013 17:12:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130804134658.GC35080@stack.nl> <20130807201934.GA4918@stack.nl> <87717220-8094-49BE-BF04-010D9788ABD3@FreeBSD.org> <20130810103036.GA40636@stack.nl> To: Jilles Tjoelker X-Mailer: Apple Mail (2.1508) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 15:12:53 -0000 Wiadomo=B6=E6 napisana przez Jilles Tjoelker w dniu 10 = sie 2013, o godz. 12:30: > On Fri, Aug 09, 2013 at 10:42:09AM +0200, Edward Tomasz Napiera=B3a = wrote: >> Wiadomo=B6=E6 napisana przez Jilles Tjoelker w dniu = 7 sie 2013, o godz. 22:19: >>> On Mon, Aug 05, 2013 at 01:13:10PM +0200, Edward Tomasz Napiera=B3a = wrote: >>>> Wiadomo=B6=E6 napisana przez Jilles Tjoelker w = dniu 4 sie 2013, o godz. 15:46: >>>>> When shutting down a service or requesting status, rc.subr = currently >>>>> uses a combination of pidfiles and process names. This is fairly = but not >>>>> completely reliable once it is set up correctly (which can take a = lot of >>>>> work and possibly patching the daemon to use pidfile(3) from our >>>>> libutil). It is also incapable of killing multiprocess daemons = such as >>>>> CGI web servers without cooperation of the daemon. >=20 >>>>> I think what is needed here is a facility that marks a process and = all >>>>> of its descendants. Removing the mark should be a privileged or at = least >>>>> an unusual operation; no unprivileged function specified by POSIX = such >>>>> as setsid() should do this. >=20 >>>> I've actually thought about that when I added setloginclass(2). = It's >>>> trivial to modify rc.subr to use su(8) to set login class for each >>>> service. It should be trivial to modify pkill(1) and killall(1) to >>>> add "-c" option to kill all processes in a given login class. >=20 >>> There are some problems with su -c: >=20 >>> * It refuses to set a login class name that is not in = /etc/login.conf. >>> Given that multiple instances of a service should each have their = own >>> kernel login class, it may make sense to allow specifying the >>> login.conf entry separate from the kernel login class. >=20 >> Indeed. I'll try to figure out something. >=20 >> FWIW, I've just committed a patch that adds "-c" flag to pkill. >=20 > On another note, init(8) does not set the kernel login class for = /etc/rc > to daemon as might be expected from the /etc/login.conf entry used. I > use this patch: >=20 > Index: sbin/init/init.c > =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 > --- sbin/init/init.c (revision 253911) > +++ sbin/init/init.c (working copy) > @@ -1729,7 +1729,8 @@ > login_cap_t *lc; > if ((lc =3D login_getclassbyname(cname, NULL)) !=3D NULL) { > setusercontext(lc, (struct passwd*)NULL, 0, > - LOGIN_SETPRIORITY | LOGIN_SETRESOURCES); > + LOGIN_SETPRIORITY | LOGIN_SETRESOURCES | > + LOGIN_SETLOGINCLASS); > login_close(lc); > } > } >=20 > Should I commit this? I think so. You also might want to add LOGIN_SETCPUMASK there. From owner-freebsd-arch@FreeBSD.ORG Sat Aug 10 21:37:57 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id D12751E7; Sat, 10 Aug 2013 21:37:57 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 986BE2258; Sat, 10 Aug 2013 21:37:56 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 84D66369; Sat, 10 Aug 2013 23:32:41 +0200 (CEST) Date: Sat, 10 Aug 2013 23:38:44 +0200 From: Pawel Jakub Dawidek To: Jilles Tjoelker Subject: Re: closedir - change in the libc Message-ID: <20130810213844.GA1400@garage.freebsd.pl> References: <5204BD94.7050800@FreeBSD.org> <20130809105934.GA32419@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline In-Reply-To: <20130809105934.GA32419@stack.nl> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@freebsd.org, Mario Oshogbo X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2013 21:37:57 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Aug 09, 2013 at 12:59:34PM +0200, Jilles Tjoelker wrote: > On Fri, Aug 09, 2013 at 11:59:48AM +0200, Mario Oshogbo wrote: > > I'm a student attending in GSoC'13 in project "Write new features for > > Capsicum" [1] and I would like to propose a little change to the libc. >=20 > > In the libc we have the function opendir(3) and fdopendir(3) which are > > responsible for opening directories. We also have function closedir(3) > > which is responsible for free the structure allocated by two previous > > funcions. >=20 > > The problem with the closedir(3) is that he close fd used as argument of > > fdopendir(3). I think programmer should be able to make a choice if he > > want to close this descriptor automatically or not. Of course we are > > able to use for dup(2) function and save fd before calling fdopendir(3) > > to prevent closing but I think this is the one syscall which we could s= ave. >=20 > > To support the propose I would like to give some example. I working now > > on making the fts(3) more sandbox friendly which means I would like to > > remove all fchdir(2) functions and operate only on fd. One of the steps > > I perform is changing the opendir(3) to the fdopendir(3). I also must > > remember the fd of currently opened directory after perform fclosedir. > > If we have N of directories we must perform N additional dup(2) and N > > additional close(2) functions to save this fd. >=20 > > So I would like to propose function called fdclosedir which will free > > DIR structure but will not close fd attached to DIR structure. This > > function also could return this fd which make it useful with the > > opendir(3) function, when we don't know the fd but we would like free > > DIR structure and perform some operations only on fd. I attach diff file > > with my proposal of change. >=20 > While this looks sensible, the only advantage is cleaner code and less > memory usage. Instead of additional dup()/close(), you could also keep > the DIR around as long as you need the fd. [...] This change is useful, I needed it in unrelated work to Mariusz's. I wanted to "borrow" my directory descriptor to some function, which were doing fdopendir(3) on it and to make it possible to not leak memory on return from this function I had to dup(2) this descriptor. I'd love to see fdclose() for similar reasons (see bin/75767, among others). --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --jRHKVT23PllUwdXP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlIGsuQACgkQForvXbEpPzSTIwCg7/rf4M4iF85ubS/HOMbCdFPC 3nsAoLbxf3cTVR0GUKH9GqDb59+Vo4AX =Spn5 -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP--