From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932275AbcHIS0g (ORCPT ); Tue, 9 Aug 2016 14:26:36 -0400 Received: from outbound1a.ore.mailhop.org ([54.213.22.21]:39441 "EHLO outbound1a.ore.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752455AbcHIS0d (ORCPT ); Tue, 9 Aug 2016 14:26:33 -0400 X-MHO-User: f0ee8a44-5e5e-11e6-a0ff-e511cd071b9b X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 74.99.77.15 X-Mail-Handler: DuoCircle Outbound SMTP X-DKIM: OpenDKIM Filter v2.6.8 io 8E81180119 Date: Tue, 9 Aug 2016 18:26:20 +0000 From: Jason Cooper To: Keith Packard Cc: Herbert Xu , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices Message-ID: <20160809182620.GF2013@io.lakedaemon.net> References: <1469477255-26824-1-git-send-email-keithp@keithp.com> <20160809095058.GA6618@gondor.apana.org.au> <20160809165710.GC2013@io.lakedaemon.net> <86y445rfiq.fsf@hiro.keithp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86y445rfiq.fsf@hiro.keithp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Keith, On Tue, Aug 09, 2016 at 10:58:05AM -0700, Keith Packard wrote: > Jason Cooper writes: > > Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a > > sysfs interface for per device quality, rate, and enabled attributes. > > e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled} > > I was interested in the data being provided for /dev/random; that seems > like the most important interface to me. Me too, agreed. > But, exposing all of the devices using consistent names does seem like > a useful idea at some level. On another thread, regarding the ath9k-rng (actually just the adc registers), Henrique asked about per-source knobs. My suggestion follows from that. > > /dev/hwrng could pull from the one with the highest quality, or user > > specified for backwards compatibility. > > I like the notion of using all of them in turn; if one of them turns out > to be broken, you're still stirring in data from the others. After all, > the quality metric is provided by the device, we aren't doing any > analysis on the data to determine it independently. Sure, but /dev/hwrng is a user interface. Typically to rngd, but not necessarily. We need to make sure it's behavior is consistent with existing expectations. We shouldn't attach first-probed to /dev/hwrng, because that may not be what the user is expecting. If I bought a raw entropy source, and knew nothing of the proposed multi-source interfaces, I'd expect the USB dongle to be attached to /dev/hwrng. Despite the fact that my pcie wifi card was probed first and has adc registers providing an entropy source. I'm not sure how we ensure that. Perhaps an 'environmental' flag in the hw_random source attributes? Or a 'not-designed-to-be-an-rng' flag? :) Maybe those would be /dev/envrng[0-9]... thx, Jason.