From owner-freebsd-hackers@freebsd.org Thu Jul 12 18:48:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE9E91033181 for ; Thu, 12 Jul 2018 18:48:28 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-io0-f169.google.com (mail-io0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6562178E45 for ; Thu, 12 Jul 2018 18:48:28 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-io0-f169.google.com with SMTP id q4-v6so29154279iob.2 for ; Thu, 12 Jul 2018 11:48:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-transfer-encoding; bh=uB6PjrapvHM190CsljEPKX5y3eVQLJuaJsU5Jl/Yd/s=; b=ANR6yegySLK+Rl+frz8QuRgRauSkMyxUtk2QO78gNxkTlAJ3tmzSq4ngFo4zWQ5HaX XLTkZ9crExwgdb+p3cxtxTHF3v5xKdmw9EFs2GagaWneUSw5ucnEDx0dzIFY4+b7qtO6 8zOnZMBxuP7x8OmQR97KXqn6pp+T3f0KZ22xi2Tqwa/EsqxhR6WtbyvPFDh02QF2dlJ2 2WgUYR0+XrHKyY8+EzZ1Koc/s3RLxUf4WZNxrks4kmCVXN3Xat/uEyxrgLxl23WoKg9p mg7yKdnFZXuYkLJRld8X3bklG4ogTyqDXJ33Z+UTR1juQEw4hQsjLEt+fE2YqT6YCkAn 6urA== X-Gm-Message-State: AOUpUlEslatkLUFcmkmdIXHrX4CGcYIpJjb+LcUtsNuVzqVQ5C01htla Vvgu45FfNIlRWIHKY2zcQxVOoKUa X-Google-Smtp-Source: AAOMgpeHtOonLsPi9Rhc4yV+CI8XxsJtzKZOzuglvlhI94pdsuKjo6RYJm75gQa06I0kyruaj+5oCA== X-Received: by 2002:a5e:c60d:: with SMTP id f13-v6mr10289686iok.197.1531420849629; Thu, 12 Jul 2018 11:40:49 -0700 (PDT) Received: from mail-io0-f173.google.com (mail-io0-f173.google.com. [209.85.223.173]) by smtp.gmail.com with ESMTPSA id r199-v6sm3432328itb.8.2018.07.12.11.40.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 11:40:49 -0700 (PDT) Received: by mail-io0-f173.google.com with SMTP id q4-v6so29134311iob.2 for ; Thu, 12 Jul 2018 11:40:49 -0700 (PDT) X-Received: by 2002:a6b:4e04:: with SMTP id c4-v6mr18980476iob.19.1531420849376; Thu, 12 Jul 2018 11:40:49 -0700 (PDT) MIME-Version: 1.0 Reply-To: cem@freebsd.org Received: by 2002:a02:7e0a:0:0:0:0:0 with HTTP; Thu, 12 Jul 2018 11:40:48 -0700 (PDT) In-Reply-To: <55685C1F-4711-40C7-8EB4-2930BF8C9884@webweaving.org> References: <3A988D26-7B08-4301-8176-B0ED8A559420@webweaving.org> <1531317515.66719.20.camel@freebsd.org> <20180712165751.1e5b8e24@gumby.homeunix.com> <7C42CD28-078F-4AF6-90F2-5E951F8386D5@webweaving.org> <55685C1F-4711-40C7-8EB4-2930BF8C9884@webweaving.org> From: Conrad Meyer Date: Thu, 12 Jul 2018 11:40:48 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Limits to seeding /dev/random | random(4) To: Dirk-Willem van Gulik Cc: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 18:48:29 -0000 On Thu, Jul 12, 2018 at 10:42 AM, Dirk-Willem van Gulik wrote: > Is there any point - much later post boot, in a non-network, read-only si= tuation with essentially just 3 or 4 user processes running with no IO or i= nteraction - to send some entropy (withewashed (or raw with random_harvest_= queue()) to wards the PRNG ? > > Or is that pointless from thereon. It isn't needed, but it doesn't hurt either (barring elevated CPU use from excessive feeding). > On 12 Jul 2018, at 19:32, Conrad Meyer wrote: >> /dev/u?random never produces unseeded results. If it is not seeded, >> reads will just block indefinitely, until it is seeded. > > As we=E2=80=99ve found out the hard way (although we are not sure it is i= ndefinitely). It is indefinite, until seeding. Maybe signals can interrupt the wait, but you should be checking the return value of read(2) of /dev/random. >> To seed the device without a writable filesystem, write 1kB+ of >> whitened random from your device into /dev/random early in boot, and >> you will be good to go. You can do the ongoing trickle after that if >> you want, but it is not necessary. On FreeBSD 12-CURRENT, you can >> verify /dev/random is seeded when getrandom(..., GRND_NONBLOCK) no >> longer returns -1 with EAGAIN errno. If you need to use a FreeBSD >> prior to 12, you'll know random is seeded when reads no longer block. > > Thanks for that. Unfortunately we=E2=80=99re in a read-only situation. An= d we=E2=80=99ve had CI testing yield identical results a few times now. Identical results are very troubling. Maybe your readonly filesystems contain a static "entropy" file that is being fed in every boot (with identical contents)? If so, you definitely want to remove that during image generation. That, in tandem with few other sources of entropy, could explain identical results. Another thing I would suggest is taking samples directly from your random device and running them through https://github.com/usnistgov/SP800-90B_EntropyAssessment to sanity check their randomness. W. Dean Freeman did some great work evaluating random sources in FreeBSD within the last couple years; you can check out his work here: https://github.com/badfilemagic/fbsd-entropy Best, Conrad