Received: by 10.192.165.148 with SMTP id m20csp1126729imm; Fri, 27 Apr 2018 13:12:07 -0700 (PDT) X-Google-Smtp-Source: AB8JxZr5pxbuMXlCfAsrZDDJ9seTlDZth6o94wIizLZFlk9qsetDKLlADXgJSjMZ37j1TrKGdW5Q X-Received: by 10.98.165.8 with SMTP id v8mr3350148pfm.225.1524859927517; Fri, 27 Apr 2018 13:12:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524859927; cv=none; d=google.com; s=arc-20160816; b=znjb05m7XgZhkch1H0YB5mlURqTMsR0TniXDi5ANa7FDYYYhszsmzAk1Cd9p+weKVm fw3OJp8xY7RLfL2uVXW0WmoCY3oxdv8bP6DGBuETP1qKK1izw+s4xb6a8/lOy/11HipQ EEl6yPaLiBYfRzhBtxL14R3aDky4AFEk4Gy7SwBlMUrWQ1LbM3cB0cl9WiIR+WvFTBCW UtH0B8HddZnHaIktYOJbUL4xwD00lQQGS+ybIRBjRmMqZN8EVCHn9nsZ05L4jpEy2kQR 0DL7v1N+1kOuXVUGM5/39b8/y46u5TBHLHDgh3KchQWmMw/0bw3hihN/26lKpEigulaj oceQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=2gpBOg4AHRi0XqlzWd7PfxbfrSvEOURCnVvL7Xi0ADs=; b=UknDdZbD3UHcgskmAOdMJQ91CDRKrAcLJyXE5mCUJB26108ZSJC9Fy95P/jMmv56CT TKZBDdykh9vPI46f1v1GeEdSAaivF3X9mhRrS4DYD8YWZ+I1XiJlCSyjXpGtXeivf+Bb Pljo77t1wM17qbRPTrMDgsAwmwbmJP8SjdkhP7lt8L7ZDiRHRyl6Z/BMNp8UBDd0yYZ5 9jSHEHnPFNUxnv9EQBenaH9DMXe2ANujJ7HMn9R0ONmVC7tLkBdzSQIzxbRYXTaIbxxG zlI/3bMt63vcjNhJpLWFutp0UpqKzm7dxFtwTlSWXGfWQLBZVwmRIxB4E8XWwGgra104 IqxQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=t3TwKVsl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i4-v6si1811869pgr.362.2018.04.27.13.11.53; Fri, 27 Apr 2018 13:12:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=t3TwKVsl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759226AbeD0UKk (ORCPT + 99 others); Fri, 27 Apr 2018 16:10:40 -0400 Received: from imap.thunk.org ([74.207.234.97]:40254 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759212AbeD0UKj (ORCPT ); Fri, 27 Apr 2018 16:10:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=2gpBOg4AHRi0XqlzWd7PfxbfrSvEOURCnVvL7Xi0ADs=; b=t3TwKVslMjIRYlvpr5glfU8UH7 GYre7xHq7Z8MUDC4Zc2RpE7VQndhiw5PFKuoRbjr7T5gACC0w/et+sZ8KpIQR0sNjt0bcg7T6ez3D CtbdiHi7VO1e+XSXp5dXyNOwxXAmX3B/y8iESlZpeO0EqymHz4ZEWMUR8D/c3hvGc2q4=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1fC9hV-00085B-Gx; Fri, 27 Apr 2018 20:10:37 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id 8E4827A0147; Fri, 27 Apr 2018 16:10:36 -0400 (EDT) Date: Fri, 27 Apr 2018 16:10:36 -0400 From: "Theodore Y. Ts'o" To: Sultan Alsawaf Cc: linux-kernel@vger.kernel.org, Jann Horn Subject: Re: Linux messages full of `random: get_random_u32 called from` Message-ID: <20180427201036.GL5965@thunk.org> Mail-Followup-To: "Theodore Y. Ts'o" , Sultan Alsawaf , linux-kernel@vger.kernel.org, Jann Horn References: <20180426050056.GF18803@thunk.org> <20180426073255.GH18803@thunk.org> <20180426192524.GD5965@thunk.org> <2add15cb-2113-0504-a732-81255ea61bf5@gmail.com> <20180426235630.GG5965@thunk.org> <3eb5761e-7b25-4178-0560-fba5eb43ce6a@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3eb5761e-7b25-4178-0560-fba5eb43ce6a@gmail.com> User-Agent: Mutt/1.9.5 (2018-04-13) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 26, 2018 at 10:20:44PM -0700, Sultan Alsawaf wrote: > > I noted at least 20,000 mmc interrupts before I intervened in the boot process to provide entropy > myself. That's just for mmc, so I'm sure there were even more interrupts elsewhere. Is 20k+ interrupts > really not sufficient? How did you determine that there were 20,000 mmc interrupts before you had logged in? Did you have access to the machine w/o having access to the login prompt? I can send a patch (see attached) that will spew large amounts of logs as each interrupt comes in and the entropy pool is getting intialized. That's how I test things on QEMU, and Jann did something similar on a (physical) test machine, so I'm pretty confident that if you were getting interrupts, it would result in them contributing into the pool. You will need a serial console, or build a kernel with a much larger dmesg buffer, since if you really are getting that many interrupts it will cause a lot of log spew. > There are lots of other sources of entropy available as well, like > the ever-changing CPU frequencies reported by any recent Intel chip > (i.e., they report precision down to 1 kHz). That's something we could look at, but the problem is if there is some systemd unit during early boot that blocks waiting for the entropy pool to be initalized, the system will come to a dead halt, and even the CPU frequency shifts will probably not move much --- just as there weren't any interrupts while some system startup on the boot path wedges the system startup waiting for entropy. This is why ultimately, we do need to attack this problem from both ends, which means teaching userspace programs to only request cryptographic-grade randomness when it is really needed --- and most of the time, if the user has not logged in yet, you probably don't need cryptographic-grade randomness.... - Ted diff --git a/drivers/char/random.c b/drivers/char/random.c index cd888d4ee605..69bd29f039e7 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -916,6 +916,10 @@ static void crng_reseed(struct crng_state *crng, struct entropy_store *r) __u32 key[8]; } buf; + if (crng == &primary_crng) + pr_notice("random: crng_reseed primary from %px\n", r); + else + pr_notice("random: crng_reseed crng %px from %px\n", crng, r); if (r) { num = extract_entropy(r, &buf, 32, 16, 0); if (num == 0) @@ -1241,6 +1245,10 @@ void add_interrupt_randomness(int irq, int irq_flags) fast_pool->pool[2] ^= ip; fast_pool->pool[3] ^= (sizeof(ip) > 4) ? ip >> 32 : get_reg(fast_pool, regs); + if (crng_init < 2) + pr_notice("random: add_interrupt(cycles=0x%08llx, now=%ld, " + "irq=%d, ip=0x%08lx)\n", + cycles, now, irq, _RET_IP_); fast_mix(fast_pool); add_interrupt_bench(cycles); @@ -1282,6 +1290,9 @@ void add_interrupt_randomness(int irq, int irq_flags) /* award one bit for the contents of the fast pool */ credit_entropy_bits(r, credit + 1); + if (crng_init < 2) + pr_notice("random: batched into pool in stage %d, bits now %d", + crng_init, ENTROPY_BITS(r)); } EXPORT_SYMBOL_GPL(add_interrupt_randomness);