All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Mackall <mpm@selenic.com>
To: Robin Getz <rgetz@blackfin.uclinux.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Chris Peterson <cpeterso@cpeterso.com>
Subject: Re: IRQF_SAMPLE_RANDOM question...
Date: Wed, 08 Apr 2009 12:51:34 -0700	[thread overview]
Message-ID: <1239220294.31467.55.camel@calx> (raw)
In-Reply-To: <200904071744.17727.rgetz@blackfin.uclinux.org>

On Tue, 2009-04-07 at 17:44 -0400, Robin Getz wrote:
> On Tue 7 Apr 2009 10:57, Matt Mackall pondered:
> > On Tue, 2009-04-07 at 07:16 -0400, Robin Getz wrote:
> > > On Mon 6 Apr 2009 15:01, Matt Mackall pondered:
> > > > On Mon, 2009-04-06 at 14:30 -0400, Robin Getz wrote:
> > > > > We have lots of embedded headless systems (no keyboard/mouse, no
> > > > > soundcard, no video) systems with *no* sources of entropy - and
> > > > > people using SSL. 
> > > > 
> > > > I'd rather add a random_sample_network call somewhere reasonably
> > > > central in the network stack. Then we can use the knowledge that the
> > > > sample is network-connected in the random core to decide how to 
> > > > measure its entropy. The trouble with IRQF_SAMPLE_RANDOM is that 
> > > > many of its users are technically bogus as entropy sources in the
> > > > current model. 
> > > 
> > > OK - that makes more sense.
> > > 
> > > Does that mean we also shouldn't be using IRQF_SAMPLE_RANDOM on
> > > interrupt sources in subsystems which already have add_xxx_randomness()
> > > in them? (block devices, and input devices?)
> > > 
> > > block/blk-core.c -> blk_end_io() -> add_disk_randomness()
> > > drivers/input/input.c -> input_event() -> add_input_randomness()
> > > 
> > >  drivers/block/xen-blkfront.c, line 639
> > > 
> > >  drivers/input/touchscreen/wm97xx-core.c, line 374
> > >  drivers/input/keyboard/gpio_keys.c, line 145
> > >  drivers/input/keyboard/bf54x-keys.c, line 255
> > >  drivers/input/serio/hp_sdc.c, line 881
> >
> > Yes. The flag needs to be taken out and shot. 
> 
> In general or just for input and block devices?
> 
> There are still some in others:
> 
> arch/arm/mach-omap1/board-palmz71.c
> arch/arm/mach-pxa/lubbock.c
> arch/arm/mach-pxa/magician.c
> arch/arm/mach-pxa/palmtx.c
> arch/arm/mach-pxa/palmz72.c
> arch/arm/mach-pxa/trizeps4.c
> arch/sparc/kernel/ldc.c
> arch/um/drivers/line.c
> arch/um/drivers/mconsole_kern.c
> arch/um/drivers/port_kern.c
> arch/um/drivers/xterm_kern.c
> arch/um/kernel/sigio.c
> arch/x86/kernel/amd_iommu_init.c
> drivers/i2c/busses/i2c-pmcmsp.c
> drivers/mfd/tps65010.c
> drivers/power/pda_power.c
> drivers/serial/bfin_sport_uart.c
> drivers/serial/mpc52xx_uart.c
> drivers/serial/uartlite.c
> drivers/staging/comedi/interrupt.h
> drivers/usb/gadget/goku_udc.c
> drivers/usb/gadget/omap_udc.c
> drivers/usb/gadget/pxa25x_udc.c
> drivers/usb/otg/gpio_vbus.c
> drivers/usb/otg/isp1301_omap.c
> 
> > Everything going into the 
> > RNG should be made to go through an add_*_randomness interface only.
> > Preferably not at a per-driver level.
> 
> Is that "Everything in general, with a few exceptions", or "__Everything__"?
> 
> If it is the latter I'll remove the ones that I'm responsible for, and send 
> Sam something for checkpatch.pl to warn if this is used in the future.

Everything. We want every input point to better document the type of
entropy source.

-- 
http://selenic.com : development and support for Mercurial and Linux



  reply	other threads:[~2009-04-09  8:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-06 18:30 IRQF_SAMPLE_RANDOM question Robin Getz
2009-04-06 18:40 ` Jeff Garzik
2009-04-06 18:44   ` Stephen Hemminger
2009-04-06 18:49     ` Jeff Garzik
2009-04-07  8:27       ` Jeremy Fitzhardinge
2009-04-06 19:22   ` Robin Getz
2009-04-06 19:00 ` Alan Cox
2009-04-06 19:01 ` Matt Mackall
2009-04-06 22:09   ` Sven-Haegar Koch
2009-04-06 23:35     ` Jeff Garzik
2009-04-07 21:58       ` Robin Getz
2009-04-07 22:25         ` Jeff Garzik
2009-04-07  0:16     ` Matt Mackall
2009-04-07  0:30       ` Jeff Garzik
2009-04-07 11:16   ` Robin Getz
2009-04-07 14:57     ` Matt Mackall
2009-04-07 21:39       ` Chris Peterson
2009-04-07 22:30         ` Robin Getz
2009-04-08 21:53           ` Gilles Espinasse
2009-04-08 23:16             ` Chris Friesen
2009-04-09  4:24               ` Robin Getz
2009-04-07 21:44       ` Robin Getz
2009-04-08 19:51         ` Matt Mackall [this message]
2009-04-09 13:54           ` Robin Getz
2009-04-09 17:00             ` Matt Mackall
2009-04-10  0:41               ` Robin Getz
2009-04-10  1:29               ` Chris Peterson
2009-04-10  2:27                 ` Matt Mackall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1239220294.31467.55.camel@calx \
    --to=mpm@selenic.com \
    --cc=cpeterso@cpeterso.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=rgetz@blackfin.uclinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.