Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753996Ab3ISNF5 (ORCPT ); Thu, 19 Sep 2013 09:05:57 -0400 Received: from terminus.zytor.com ([198.137.202.10]:59810 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752033Ab3ISNF4 (ORCPT ); Thu, 19 Sep 2013 09:05:56 -0400 User-Agent: K-9 Mail for Android In-Reply-To: References: <52322621.3040908@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Resend PATCH 2/2] s390: provide hardware randomness from zcrypt card to /dev/random From: "H. Peter Anvin" Date: Thu, 19 Sep 2013 08:05:32 -0500 To: Torsten Duwe , Torsten Duwe CC: tytso@mit.edu, ingo.tuchscherer@de.ibm.com, linux-kernel@vger.kernel.org, Hans-Georg Markgraf , Gerald Schaefer , Martin Schwidefsky , Heiko Carstens , Joe Perches Message-ID: <33dd164b-00a7-4cbd-9d62-66000ed4abbf@email.android.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2210 Lines: 58 As I said, the option of doing feed from hwrng directly via a kernel thread seems the most logical thing to me, assuming you can convince Ted & co. rngd doesn't really add much value for a whitened source. Torsten Duwe wrote: > > >On Thu, 12 Sep 2013, H. Peter Anvin wrote: > >> From what I can gather from the patch this is too heavyweight (need >> locks and so on) to use as arch_get_random*(). There has been a lot >of > >Alas, I can see there's only x86 that currently has this implemented? > >> discussion about the pros and cons of allowing the kernel to bypass >> rngd, but I would think that any such plumbing -- once it gets past >the >> fully synchronous low latency properties of arch_get_random*() -- >really >> should be implemented as an option in the existing hwrng device >> infrastructure. > >As I wrote in the intro, the problem to solve is slow startup when ASLR >is >in effect; in that case: until rngd or haveged is finally running. > >> In other words, start by implementing a hwrng device. That will work >> right now with rngd running. Then we can consider if we want to >allow > >That's already there, thanks to the IBM guys :) > >> bypass of rngd for certain hwrng devices -- which may include zcrypt, >> virtio_rng and so on. > >I'm currently thinking about some kind of buffer in zcrypt, where >arch_get_random can get a long or int quickly, as "designed" after x86. >Device init or low water would trigger a work item to refill the >buffer. >It might tun out though, that every device on every architecture that >does >not quite match the x86 approach implements its own buffer. > >What do you think? > >Besides that, as you wrote, a generic mechanism to mix hwrngs into the >input pool would be nice, triggered by user space policy. As far as I >can >see, some mixing of arch_get_random is done, but no entropy credited? > > Torsten -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/