From owner-freebsd-current@FreeBSD.ORG Sat Sep 7 20:42:02 2013 Return-Path: Delivered-To: freebsd-current@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 61C2ECD9; Sat, 7 Sep 2013 20:42:02 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CC4C92479; Sat, 7 Sep 2013 20:42:01 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj3so2097934wib.1 for ; Sat, 07 Sep 2013 13:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ahBkgSx7NAummxXDrMRkNnbyTSVOz6IYn/lpoDS/bRA=; b=NVLb2ToA73xISPFYUYsQvFp0W5lXO+92jF/B51py8HMIhMAcQCdAa6wisPdH4ZnZC5 qN75hmKR7/vfErBjqf7OjXQOszWy9PwhW6TSXaehQFSoDCv0w+Bph3hNkbxgYLyU2r6a iThno61q+CtFffqec6/pOYKocdaX9lqwueFQCB3ZGyMqp3RXzI59/0fTIiyfx4Cs2bBv 7qmTsRC4Hf6hzR9px1CwwBKh/dEZvHhz+ynKnYV+VACt8ZNWmwWhQrTK8jle/05QDlrs 9147xW+jAHFzrZKNCOW0pl05hR4tD7L7A3AFfNQ3jdaOnYAZL2t8xl1DHXXMmX+N8DkT 4HyQ== MIME-Version: 1.0 X-Received: by 10.180.211.206 with SMTP id ne14mr3137087wic.30.1378586520186; Sat, 07 Sep 2013 13:42:00 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.73.133 with HTTP; Sat, 7 Sep 2013 13:42:00 -0700 (PDT) In-Reply-To: <1378586316.1111.524.camel@revolution.hippie.lan> References: <1378572186.1588.5.camel@localhost> <24DB010A-F374-491B-9203-FDDD7EA14A51@grondar.org> <1378579011.1588.16.camel@localhost> <9240BEF1-2791-4D58-A422-08AEF1CD306C@grondar.org> <1378586316.1111.524.camel@revolution.hippie.lan> Date: Sat, 7 Sep 2013 13:42:00 -0700 X-Google-Sender-Auth: PKTpISkO17Cr85SZ8RrCanUgVso Message-ID: Subject: Re: random(4) update causes mips compile fail | mips boot fail From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-current@freebsd.org" , Mark R V Murray X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Sep 2013 20:42:02 -0000 Hi! On 7 September 2013 13:38, Ian Lepore wrote: > I keep trying to say this, and I keep getting the feeling that it just > doesn't register with anyone I say it to, like I'm speaking some > language from another planet or something... > > There may be NO entropy of any sort available on an embedded system, and > you cannot block the ability to boot and run such a system just because > you think it's a bad idea to run without sufficient randomness. It's > not your call to make -- it's a decision for the person using or > administering the system. > > You must provide a mechanism that disables the blocking behavior. The > mechanism must be either a kernel compile-time config knob (not all > platforms use loader(8) or anything else that can set a tunable var), or > something in the rc system that can unblock /dev/random before anything > else needs it. The latter implies that the kernel itself must not block > before getting to that point in rc processing, even if it needs random > numbers for something (like cooking up a temporary MAC address). > > It's okay to make it hard to do the wrong thing by accident. It's not > okay to make it impossible to do that thing on purpose. > We discussed this at the dev summit. Mark asked what we'd like to do. Mark - would you mind terribly adding a kernel compile option that controls that blocking default, so we can flip it on for the ARM/MIPS boards that don't have a hardware PRNG to start seeding things with? -adrian