* IRQF_SAMPLE_RANDOM question...
@ 2009-04-06 18:30 Robin Getz
2009-04-06 18:40 ` Jeff Garzik
` (2 more replies)
0 siblings, 3 replies; 28+ messages in thread
From: Robin Getz @ 2009-04-06 18:30 UTC (permalink / raw)
To: netdev, linux-kernel, Chris Peterson, Matt Mackall
Although there was some discussion
http://thread.gmane.org/gmane.linux.kernel/680723
about removing IRQF_SAMPLE_RANDOM from the remaining network drivers in May of
2008, but they still appears to be there in 2.6.29.
drivers/net/ibmlana.c
drivers/net/macb.c
drivers/net/3c523.c
drivers/net/3c527.c
drivers/net/netxen/netxen_nic_main.c
drivers/net/cris/eth_v10.c
drivers/net/xen-netfront.c
drivers/net/atlx/atl1.c
drivers/net/qla3xxx.c
drivers/net/tg3.c
drivers/net/niu.c
So what is the plan? If I send a patch to add IRQF_SAMPLE_RANDOM to others
(like the Blackfin) networking drivers - will it get rejected?
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 didn't really find any docs which describe what should have
IRQF_SAMPLE_RANDOM on it or not. I did find Matt Mackall describing it as:
> We currently assume that IRQF_SAMPLE_RANDOM means 'this is a completely
> trusted unobservable entropy source' which is obviously wrong for
> network devices but is right for some other classes of device.
Currently - I see most things I see using IRQF_SAMPLE_RANDOM would also fail
the "completely unobservable" test. Other than the TRNG that are inside the
CPU - what does pass?
I can put a scope/analyser on a device - and look at the touchscreens, serial
devices, USB, all without cracking the case.
drivers/block/xen-blkfront.c: Xen virtual block device frontend
drivers/i2c/busses/i2c-pmcmsp.c: PMC MSP TWI/SMBus/I2C driver
drivers/input/keyboard/bf54x-keys.c: Keypad driver for BF54x Processors
drivers/input/keyboard/gpio_keys.c: Keyboard driver for CPU GPIOs
drivers/input/serio/hp_sdc.c: HP i8042-based SDC Driver
drivers/input/touchscreen/wm97xx-core.c: WM97xx Core - Touch Screen
drivers/serial/mpc52xx_uart.c: Freescale MPC52xx PSC UART
drivers/serial/uartlite.c: Xilinx uartlite serial driver
drivers/usb/gadget/omadrivers/usb/gadget/omap_udc OMAP UDC driver
If I want to get more intrusive (expensive) - I can look at SPI, I2C, and
other things that only might be observable at the PCB level (including things
that are inside the chipset).
What are the guidelines for including IRQF_SAMPLE_RANDOM?
Thanks
-Robin
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 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 19:22 ` Robin Getz 2009-04-06 19:00 ` Alan Cox 2009-04-06 19:01 ` Matt Mackall 2 siblings, 2 replies; 28+ messages in thread From: Jeff Garzik @ 2009-04-06 18:40 UTC (permalink / raw) To: Robin Getz Cc: netdev, linux-kernel, Chris Peterson, Matt Mackall, David Miller Robin Getz wrote: > Although there was some discussion > http://thread.gmane.org/gmane.linux.kernel/680723 > > about removing IRQF_SAMPLE_RANDOM from the remaining network drivers in May of > 2008, but they still appears to be there in 2.6.29. > > drivers/net/ibmlana.c > drivers/net/macb.c > drivers/net/3c523.c > drivers/net/3c527.c > drivers/net/netxen/netxen_nic_main.c > drivers/net/cris/eth_v10.c > drivers/net/xen-netfront.c > drivers/net/atlx/atl1.c > drivers/net/qla3xxx.c > drivers/net/tg3.c > drivers/net/niu.c > > So what is the plan? If I send a patch to add IRQF_SAMPLE_RANDOM to others > (like the Blackfin) networking drivers - will it get rejected? > > 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 didn't really find any docs which describe what should have > IRQF_SAMPLE_RANDOM on it or not. I did find Matt Mackall describing it as: >> We currently assume that IRQF_SAMPLE_RANDOM means 'this is a completely >> trusted unobservable entropy source' which is obviously wrong for >> network devices but is right for some other classes of device. > > Currently - I see most things I see using IRQF_SAMPLE_RANDOM would also fail > the "completely unobservable" test. Other than the TRNG that are inside the > CPU - what does pass? IMO it's not observation but rather that a remote host is essentially your source of entropy -- which means your source of entropy is potentially controllable or influenced by an attacker. Furthermore, with hardware interrupt mitigation, non-trivial traffic levels can imply that interrupts are delivered with timer-based regularity. This, too, may clearly be influenced by a remote attacker. Thus I think IRQF_SAMPLE_RANDOM should be banned from network drivers... but that is not a universal opinion. Jeff ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-06 18:40 ` Jeff Garzik @ 2009-04-06 18:44 ` Stephen Hemminger 2009-04-06 18:49 ` Jeff Garzik 2009-04-06 19:22 ` Robin Getz 1 sibling, 1 reply; 28+ messages in thread From: Stephen Hemminger @ 2009-04-06 18:44 UTC (permalink / raw) To: Jeff Garzik Cc: Robin Getz, netdev, linux-kernel, Chris Peterson, Matt Mackall, David Miller On Mon, 06 Apr 2009 14:40:05 -0400 Jeff Garzik <jeff@garzik.org> wrote: > Robin Getz wrote: > > Although there was some discussion > > http://thread.gmane.org/gmane.linux.kernel/680723 > > > > about removing IRQF_SAMPLE_RANDOM from the remaining network drivers in May of > > 2008, but they still appears to be there in 2.6.29. > > > > drivers/net/ibmlana.c > > drivers/net/macb.c > > drivers/net/3c523.c > > drivers/net/3c527.c > > drivers/net/netxen/netxen_nic_main.c > > drivers/net/cris/eth_v10.c > > drivers/net/xen-netfront.c > > drivers/net/atlx/atl1.c > > drivers/net/qla3xxx.c > > drivers/net/tg3.c > > drivers/net/niu.c > > > > So what is the plan? If I send a patch to add IRQF_SAMPLE_RANDOM to others > > (like the Blackfin) networking drivers - will it get rejected? > > > > 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 didn't really find any docs which describe what should have > > IRQF_SAMPLE_RANDOM on it or not. I did find Matt Mackall describing it as: > >> We currently assume that IRQF_SAMPLE_RANDOM means 'this is a completely > >> trusted unobservable entropy source' which is obviously wrong for > >> network devices but is right for some other classes of device. > > > > Currently - I see most things I see using IRQF_SAMPLE_RANDOM would also fail > > the "completely unobservable" test. Other than the TRNG that are inside the > > CPU - what does pass? > > IMO it's not observation but rather that a remote host is essentially > your source of entropy -- which means your source of entropy is > potentially controllable or influenced by an attacker. > > Furthermore, with hardware interrupt mitigation, non-trivial traffic > levels can imply that interrupts are delivered with timer-based > regularity. This, too, may clearly be influenced by a remote attacker. > > Thus I think IRQF_SAMPLE_RANDOM should be banned from network drivers... > but that is not a universal opinion. > > Jeff The real problem one is xen-netfront. Because 1) it is least random, the attacker might be another VM 2) the VM is most in need of random samples because it doesn't have real hardware. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-06 18:44 ` Stephen Hemminger @ 2009-04-06 18:49 ` Jeff Garzik 2009-04-07 8:27 ` Jeremy Fitzhardinge 0 siblings, 1 reply; 28+ messages in thread From: Jeff Garzik @ 2009-04-06 18:49 UTC (permalink / raw) To: Stephen Hemminger Cc: Robin Getz, netdev, linux-kernel, Chris Peterson, Matt Mackall, David Miller Stephen Hemminger wrote: > The real problem one is xen-netfront. Because 1) it is least random, > the attacker might be another VM 2) the VM is most in need of random > samples because it doesn't have real hardware. Agreed. I'm surprised Xen doesn't use virtio-rng. I guess it needs a special Xen paravirt driver for randomness. Jeff ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-06 18:49 ` Jeff Garzik @ 2009-04-07 8:27 ` Jeremy Fitzhardinge 0 siblings, 0 replies; 28+ messages in thread From: Jeremy Fitzhardinge @ 2009-04-07 8:27 UTC (permalink / raw) To: Jeff Garzik Cc: Stephen Hemminger, Robin Getz, netdev, linux-kernel, Chris Peterson, Matt Mackall, David Miller Jeff Garzik wrote: > Stephen Hemminger wrote: >> The real problem one is xen-netfront. Because 1) it is least random, >> the attacker might be another VM 2) the VM is most in need of random >> samples because it doesn't have real hardware. > > Agreed. > > I'm surprised Xen doesn't use virtio-rng. I guess it needs a special > Xen paravirt driver for randomness. Yes, sampling randomness in a PV driver is pretty pointless. We could do the guest end of an entropy sink entirely in usermode, but at present there's no dom0 support for an entropy source. J ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-06 18:40 ` Jeff Garzik 2009-04-06 18:44 ` Stephen Hemminger @ 2009-04-06 19:22 ` Robin Getz 1 sibling, 0 replies; 28+ messages in thread From: Robin Getz @ 2009-04-06 19:22 UTC (permalink / raw) To: Jeff Garzik Cc: netdev, linux-kernel, Chris Peterson, Matt Mackall, David Miller On Mon 6 Apr 2009 14:40, Jeff Garzik pondered: > Robin Getz wrote: > > Although there was some discussion > > http://thread.gmane.org/gmane.linux.kernel/680723 > > > > about removing IRQF_SAMPLE_RANDOM from the remaining network drivers > > in May of 2008, but they still appears to be there in 2.6.29. > > > > drivers/net/ibmlana.c > > drivers/net/macb.c > > drivers/net/3c523.c > > drivers/net/3c527.c > > drivers/net/netxen/netxen_nic_main.c > > drivers/net/cris/eth_v10.c > > drivers/net/xen-netfront.c > > drivers/net/atlx/atl1.c > > drivers/net/qla3xxx.c > > drivers/net/tg3.c > > drivers/net/niu.c > > > > So what is the plan? If I send a patch to add IRQF_SAMPLE_RANDOM to others > > (like the Blackfin) networking drivers - will it get rejected? > > > > 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 didn't really find any docs which describe what should have > > IRQF_SAMPLE_RANDOM on it or not. I did find Matt Mackall describing it as: > >> We currently assume that IRQF_SAMPLE_RANDOM means 'this is a completely > >> trusted unobservable entropy source' which is obviously wrong for > >> network devices but is right for some other classes of device. > > > > Currently - I see most things I see using IRQF_SAMPLE_RANDOM would > > also fail the "completely unobservable" test. Other than the TRNG that > > are inside the CPU - what does pass? > > IMO it's not observation but rather that a remote host is essentially > your source of entropy -- which means your source of entropy is > potentially controllable or influenced by an attacker. Ok - so if it is "un-influenceable" or more specifically - not remotely influenceable - that works for me, and says that keyboards, serial devices, USB, etc -- should be OK - since they are not remote, even if they can be controlled locally. You assume that the local user is the root user - as least as far as entropy goes? Correct? > Furthermore, with hardware interrupt mitigation, non-trivial traffic > levels can imply that interrupts are delivered with timer-based > regularity. This, too, may clearly be influenced by a remote attacker. > > Thus I think IRQF_SAMPLE_RANDOM should be banned from network drivers... > but that is not a universal opinion. It didn't seem like there were that many people who disagreed with Chris's original patch - but there wasn't anyone acking it either... -Robin ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-06 18:30 IRQF_SAMPLE_RANDOM question Robin Getz 2009-04-06 18:40 ` Jeff Garzik @ 2009-04-06 19:00 ` Alan Cox 2009-04-06 19:01 ` Matt Mackall 2 siblings, 0 replies; 28+ messages in thread From: Alan Cox @ 2009-04-06 19:00 UTC (permalink / raw) To: Robin Getz; +Cc: netdev, linux-kernel, Chris Peterson, Matt Mackall On Mon, 6 Apr 2009 14:30:26 -0400 Robin Getz <rgetz@blackfin.uclinux.org> wrote: > Although there was some discussion > http://thread.gmane.org/gmane.linux.kernel/680723 > > about removing IRQF_SAMPLE_RANDOM from the remaining network drivers in May of > 2008, but they still appears to be there in 2.6.29. These are mostly unmaintained drivers. Dunno why tg3 isn't fixed - it has some mitigation logic so maybe its not observable > I can put a scope/analyser on a device - and look at the touchscreens, serial > devices, USB, all without cracking the case. But you can observe a network interface accurately from all over the lan (and with a ten dollar card), or a good deal further (I believe up to 1Km in the right conditions was claimed by some If you need absolute hard entropy then use a real entropy source, if not then your user space is using the wrong device file - the blocking for entropy one. At that point it depends how vital your SSL is to you and what it protects. Alan ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-06 18:30 IRQF_SAMPLE_RANDOM question Robin Getz 2009-04-06 18:40 ` Jeff Garzik 2009-04-06 19:00 ` Alan Cox @ 2009-04-06 19:01 ` Matt Mackall 2009-04-06 22:09 ` Sven-Haegar Koch 2009-04-07 11:16 ` Robin Getz 2 siblings, 2 replies; 28+ messages in thread From: Matt Mackall @ 2009-04-06 19:01 UTC (permalink / raw) To: Robin Getz; +Cc: netdev, linux-kernel, Chris Peterson On Mon, 2009-04-06 at 14:30 -0400, Robin Getz wrote: > Although there was some discussion > http://thread.gmane.org/gmane.linux.kernel/680723 > > about removing IRQF_SAMPLE_RANDOM from the remaining network drivers in May of > 2008, but they still appears to be there in 2.6.29. > > drivers/net/ibmlana.c > drivers/net/macb.c > drivers/net/3c523.c > drivers/net/3c527.c > drivers/net/netxen/netxen_nic_main.c > drivers/net/cris/eth_v10.c > drivers/net/xen-netfront.c > drivers/net/atlx/atl1.c > drivers/net/qla3xxx.c > drivers/net/tg3.c > drivers/net/niu.c > > So what is the plan? If I send a patch to add IRQF_SAMPLE_RANDOM to others > (like the Blackfin) networking drivers - will it get rejected? > > 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. I'm eventually going to move the RNG away from the strict theoretical entropy accounting model to a more pragmatic one which will be much happier with iffy entropy sources, but that's a ways off. -- http://selenic.com : development and support for Mercurial and Linux ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 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 0:16 ` Matt Mackall 2009-04-07 11:16 ` Robin Getz 1 sibling, 2 replies; 28+ messages in thread From: Sven-Haegar Koch @ 2009-04-06 22:09 UTC (permalink / raw) To: Matt Mackall; +Cc: Robin Getz, netdev, linux-kernel, Chris Peterson On Mon, 6 Apr 2009, Matt Mackall wrote: > 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. > > I'm eventually going to move the RNG away from the strict theoretical > entropy accounting model to a more pragmatic one which will be much > happier with iffy entropy sources, but that's a ways off. Btw, perhaps not the perfect question in this thread: But what should we use to keep servers running without a hardware rng available and without any external input besides the network? After having ssh and openvpn die because of no random and having the machines like dead and unreachable for me I use "ln -sf /dev/urandom /dev/random", but that does not feel so good. c'ya sven -- The lights are fading out, once more... ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 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 0:16 ` Matt Mackall 1 sibling, 1 reply; 28+ messages in thread From: Jeff Garzik @ 2009-04-06 23:35 UTC (permalink / raw) To: Sven-Haegar Koch Cc: Matt Mackall, Robin Getz, netdev, linux-kernel, Chris Peterson Sven-Haegar Koch wrote: > On Mon, 6 Apr 2009, Matt Mackall wrote: > >> 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. >> >> I'm eventually going to move the RNG away from the strict theoretical >> entropy accounting model to a more pragmatic one which will be much >> happier with iffy entropy sources, but that's a ways off. > > Btw, perhaps not the perfect question in this thread: > But what should we use to keep servers running without a hardware rng > available and without any external input besides the network? > After having ssh and openvpn die because of no random and having > the machines like dead and unreachable for me I use "ln -sf > /dev/urandom /dev/random", but that does not feel so good. We see this question every time IRQF_SAMPLE_RANDOM is discussed. There is plenty of entropy data available, you just have to look around... Google around for "EGD", video entropy daemon, audio entropy daemon, etc... Even headless servers have entropy sources if you look hard enough. Jeff ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-06 23:35 ` Jeff Garzik @ 2009-04-07 21:58 ` Robin Getz 2009-04-07 22:25 ` Jeff Garzik 0 siblings, 1 reply; 28+ messages in thread From: Robin Getz @ 2009-04-07 21:58 UTC (permalink / raw) To: Jeff Garzik Cc: Sven-Haegar Koch, Matt Mackall, netdev, linux-kernel, Chris Peterson On Mon 6 Apr 2009 19:35, Jeff Garzik pondered: > Sven-Haegar Koch wrote: > > On Mon, 6 Apr 2009, Matt Mackall wrote: > > > >> 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. > >> > >> I'm eventually going to move the RNG away from the strict theoretical > >> entropy accounting model to a more pragmatic one which will be much > >> happier with iffy entropy sources, but that's a ways off. > > > > Btw, perhaps not the perfect question in this thread: > > But what should we use to keep servers running without a hardware rng > > available and without any external input besides the network? > > After having ssh and openvpn die because of no random and having > > the machines like dead and unreachable for me I use "ln -sf > > /dev/urandom /dev/random", but that does not feel so good. > > We see this question every time IRQF_SAMPLE_RANDOM is discussed. > > There is plenty of entropy data available, you just have to look > around... Google around for "EGD", video entropy daemon, audio entropy > daemon, etc... > > Even headless servers have entropy sources if you look hard enough. The original question wasn't headless servers - it was headless, no audio, no video, boot from flash, (initrd root file systems), diskless. embedded devices. And few want to load up perl on an embedded device just to gather entropy. :( -Robin ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-07 21:58 ` Robin Getz @ 2009-04-07 22:25 ` Jeff Garzik 0 siblings, 0 replies; 28+ messages in thread From: Jeff Garzik @ 2009-04-07 22:25 UTC (permalink / raw) To: Robin Getz Cc: Sven-Haegar Koch, Matt Mackall, netdev, linux-kernel, Chris Peterson Robin Getz wrote: > On Mon 6 Apr 2009 19:35, Jeff Garzik pondered: >> Sven-Haegar Koch wrote: >>> On Mon, 6 Apr 2009, Matt Mackall wrote: >>> >>>> 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. >>>> >>>> I'm eventually going to move the RNG away from the strict theoretical >>>> entropy accounting model to a more pragmatic one which will be much >>>> happier with iffy entropy sources, but that's a ways off. >>> Btw, perhaps not the perfect question in this thread: >>> But what should we use to keep servers running without a hardware rng >>> available and without any external input besides the network? >>> After having ssh and openvpn die because of no random and having >>> the machines like dead and unreachable for me I use "ln -sf >>> /dev/urandom /dev/random", but that does not feel so good. >> We see this question every time IRQF_SAMPLE_RANDOM is discussed. >> >> There is plenty of entropy data available, you just have to look >> around... Google around for "EGD", video entropy daemon, audio entropy >> daemon, etc... >> >> Even headless servers have entropy sources if you look hard enough. > > The original question wasn't headless servers - it was headless, no audio, no > video, boot from flash, (initrd root file systems), diskless. embedded > devices. > > And few want to load up perl on an embedded device just to gather entropy. :( Get a list of <special files> from EGD, and cat <special files> | sha1sum then... The basic point is that you can find entropy, even in a guest VM. Jeff ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-06 22:09 ` Sven-Haegar Koch 2009-04-06 23:35 ` Jeff Garzik @ 2009-04-07 0:16 ` Matt Mackall 2009-04-07 0:30 ` Jeff Garzik 1 sibling, 1 reply; 28+ messages in thread From: Matt Mackall @ 2009-04-07 0:16 UTC (permalink / raw) To: Sven-Haegar Koch; +Cc: Robin Getz, netdev, linux-kernel, Chris Peterson On Tue, 2009-04-07 at 00:09 +0200, Sven-Haegar Koch wrote: > On Mon, 6 Apr 2009, Matt Mackall wrote: > > > 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. > > > > I'm eventually going to move the RNG away from the strict theoretical > > entropy accounting model to a more pragmatic one which will be much > > happier with iffy entropy sources, but that's a ways off. > > Btw, perhaps not the perfect question in this thread: > But what should we use to keep servers running without a hardware rng > available and without any external input besides the network? > After having ssh and openvpn die because of no random and having > the machines like dead and unreachable for me I use "ln -sf > /dev/urandom /dev/random", but that does not feel so good. It's fine so long as you're not wearing a tinfoil hat. In fact, as the /dev/random maintainer, I'd recommend it. Ted and I have recently been talking about revisiting the design of /dev/random to avoid these sorts of issues. -- http://selenic.com : development and support for Mercurial and Linux ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-07 0:16 ` Matt Mackall @ 2009-04-07 0:30 ` Jeff Garzik 0 siblings, 0 replies; 28+ messages in thread From: Jeff Garzik @ 2009-04-07 0:30 UTC (permalink / raw) To: Matt Mackall Cc: Sven-Haegar Koch, Robin Getz, netdev, linux-kernel, Chris Peterson Matt Mackall wrote: > On Tue, 2009-04-07 at 00:09 +0200, Sven-Haegar Koch wrote: >> On Mon, 6 Apr 2009, Matt Mackall wrote: >> >>> 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. >>> >>> I'm eventually going to move the RNG away from the strict theoretical >>> entropy accounting model to a more pragmatic one which will be much >>> happier with iffy entropy sources, but that's a ways off. >> Btw, perhaps not the perfect question in this thread: >> But what should we use to keep servers running without a hardware rng >> available and without any external input besides the network? >> After having ssh and openvpn die because of no random and having >> the machines like dead and unreachable for me I use "ln -sf >> /dev/urandom /dev/random", but that does not feel so good. > > It's fine so long as you're not wearing a tinfoil hat. In fact, as > the /dev/random maintainer, I'd recommend it. > > Ted and I have recently been talking about revisiting the design > of /dev/random to avoid these sorts of issues. Two points... - while I would welcome a more pragmatic entropy accounting model, - it seems misplaced to _solely_ address network entropy problems (timer-based regularity, external visibility and access) within the devrandom machinery. IRQF_SAMPLE_RANDOM in network drivers IMO just gives users a false sense of security about their entropy. And more fundamentally, IRQF_SAMPLE_RANDOM should never be used on a non-random source. Jeff ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-06 19:01 ` Matt Mackall 2009-04-06 22:09 ` Sven-Haegar Koch @ 2009-04-07 11:16 ` Robin Getz 2009-04-07 14:57 ` Matt Mackall 1 sibling, 1 reply; 28+ messages in thread From: Robin Getz @ 2009-04-07 11:16 UTC (permalink / raw) To: Matt Mackall; +Cc: netdev, linux-kernel, Chris Peterson 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 > I'm eventually going to move the RNG away from the strict theoretical > entropy accounting model to a more pragmatic one which will be much > happier with iffy entropy sources, but that's a ways off. Looking forward to it. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-07 11:16 ` Robin Getz @ 2009-04-07 14:57 ` Matt Mackall 2009-04-07 21:39 ` Chris Peterson 2009-04-07 21:44 ` Robin Getz 0 siblings, 2 replies; 28+ messages in thread From: Matt Mackall @ 2009-04-07 14:57 UTC (permalink / raw) To: Robin Getz; +Cc: netdev, linux-kernel, Chris Peterson 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. Everything going into the RNG should be made to go through an add_*_randomness interface only. Preferably not at a per-driver level. -- http://selenic.com : development and support for Mercurial and Linux ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-07 14:57 ` Matt Mackall @ 2009-04-07 21:39 ` Chris Peterson 2009-04-07 22:30 ` Robin Getz 2009-04-07 21:44 ` Robin Getz 1 sibling, 1 reply; 28+ messages in thread From: Chris Peterson @ 2009-04-07 21:39 UTC (permalink / raw) To: Matt Mackall; +Cc: Robin Getz, netdev, linux-kernel 1. Are there any new add_*_randomness() functions that could be added? Some userspace daemons like EGD (running as root) feed random system info (e.g. vmstat) into /dev/random. But how many Linux distros actually run entropy-gathering daemons by default? Would /dev/random be more secure if entropy-gathering daemons were replaced with new kernel functions like add_vmstat_randomness() or add_ps_randomness()? 2. Are there any other functions that could be calling the existing add_*_randomness() functions? Currently: * add_input_randomness() is called from input_event(). * add_interrupt_randomess() is called from handle_IRQ_event() if IRQF_SAMPLE_RANDOM is set. * add_disk_randomness() is called from blk_end_io() and __blk_end_request(). ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-07 21:39 ` Chris Peterson @ 2009-04-07 22:30 ` Robin Getz 2009-04-08 21:53 ` Gilles Espinasse 0 siblings, 1 reply; 28+ messages in thread From: Robin Getz @ 2009-04-07 22:30 UTC (permalink / raw) To: Chris Peterson; +Cc: Matt Mackall, netdev, linux-kernel On Tue 7 Apr 2009 17:39, Chris Peterson pondered: > 1. Are there any new add_*_randomness() functions that could be added? I can think of - USB, serial, SDIO - but if any are heavily loaded with constant data - their randomness reduces, and becomes less useful. if it is the normal use case - then these might be better - but it is a function of the local users's use of the device - and is not remotely attackable. > Some userspace daemons like EGD (running as root) feed random system > info (e.g. vmstat) into /dev/random. But how many Linux distros > actually run entropy-gathering daemons by default? Not many that I can find. > Would /dev/random > be more secure if entropy-gathering daemons were replaced with new > kernel functions like add_vmstat_randomness() or add_ps_randomness()? on embedded and server - it is likely most of ps (except load) will be pretty stable - even vmstat - might be on more stable than you think on embedded - which starts processes, allocates memory, and then just runs forever..... > 2. Are there any other functions that could be calling the existing > add_*_randomness() functions? Currently: > > * add_input_randomness() is called from input_event(). Could be added in the serial core? usb? spi? i2c? > * add_interrupt_randomess() is called from handle_IRQ_event() if > IRQF_SAMPLE_RANDOM is set. > * add_disk_randomness() is called from blk_end_io() and __blk_end_request(). ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-07 22:30 ` Robin Getz @ 2009-04-08 21:53 ` Gilles Espinasse 2009-04-08 23:16 ` Chris Friesen 0 siblings, 1 reply; 28+ messages in thread From: Gilles Espinasse @ 2009-04-08 21:53 UTC (permalink / raw) To: Robin Getz, Chris Peterson; +Cc: Matt Mackall, netdev, linux-kernel ----- Original Message ----- From: "Robin Getz" <rgetz@blackfin.uclinux.org> To: "Chris Peterson" <cpeterso@cpeterso.com> Cc: "Matt Mackall" <mpm@selenic.com>; <netdev@vger.kernel.org>; <linux-kernel@vger.kernel.org> Sent: Wednesday, April 08, 2009 12:30 AM Subject: Re: IRQF_SAMPLE_RANDOM question... > > on embedded and server - it is likely most of ps (except load) will be pretty > stable - even vmstat - might be on more stable than you think on embedded - > which starts processes, allocates memory, and then just runs forever..... > After the topic on that subject in May, I find clrngd http://ipsec.pl/files/ipsec/clrngd-1.0.3.tar.gz That's a small C program that feed /dev/random Readme say : "This daemon attempts to collect real randomness from fluctuations of high-frequency clocks on a PC's mainboard. The basic assumption is that mainboard and CPU are clocked by two separate physical clocks." Shortly tested, look to work for me. How large is this basic assumption true, on x86, on other arch? Gilles ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-08 21:53 ` Gilles Espinasse @ 2009-04-08 23:16 ` Chris Friesen 2009-04-09 4:24 ` Robin Getz 0 siblings, 1 reply; 28+ messages in thread From: Chris Friesen @ 2009-04-08 23:16 UTC (permalink / raw) To: Gilles Espinasse Cc: Robin Getz, Chris Peterson, Matt Mackall, netdev, linux-kernel Gilles Espinasse wrote: > Readme say : > "This daemon attempts to collect real randomness from fluctuations of > high-frequency clocks on a PC's mainboard. The basic assumption is that > mainboard and CPU are clocked by two separate physical clocks." > How large is this basic assumption true, on x86, on other arch? Isn't the cpu frequency normally a phase-locked multiple of the mainboard bus frequency? Chris ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-08 23:16 ` Chris Friesen @ 2009-04-09 4:24 ` Robin Getz 0 siblings, 0 replies; 28+ messages in thread From: Robin Getz @ 2009-04-09 4:24 UTC (permalink / raw) To: Chris Friesen Cc: Gilles Espinasse, Chris Peterson, Matt Mackall, netdev, linux-kernel On Wed 8 Apr 2009 19:16, Chris Friesen pondered: > Gilles Espinasse wrote: > > > Readme say : > > "This daemon attempts to collect real randomness from fluctuations of > > high-frequency clocks on a PC's mainboard. The basic assumption is that > > mainboard and CPU are clocked by two separate physical clocks." > > > How large is this basic assumption true, on x86, on other arch? > > Isn't the cpu frequency normally a phase-locked multiple of the > mainboard bus frequency? Yes - typically they are the same. However - I have tested clrngd out on a Blackfin, and found it gave an excessively high load - but it did give ok results. 77% of the time (659/848 times) it provided results that passed it's built in FIPS test. It did die a few times (if the FIPS tests fails 5 times in a row clrngd aborts). I was going to write my own (based on a similar architecture) - but use the RTC clock and the main clock - since those actually would be different physical crystals - and the accuracy of low cost 32kHz crystals is crappy (typically measureable with a high enough core clock). But I think delays of cache misses/flushes will dominate things anyway - which is why clrngd works today on systems which are using the same clock source. (but since it will be RTC interrupt driven, vs while(1){} like clrngd - the load will be much lower). -Robin ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-07 14:57 ` Matt Mackall 2009-04-07 21:39 ` Chris Peterson @ 2009-04-07 21:44 ` Robin Getz 2009-04-08 19:51 ` Matt Mackall 1 sibling, 1 reply; 28+ messages in thread From: Robin Getz @ 2009-04-07 21:44 UTC (permalink / raw) To: Matt Mackall; +Cc: netdev, linux-kernel, Chris Peterson 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. -Robin ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-07 21:44 ` Robin Getz @ 2009-04-08 19:51 ` Matt Mackall 2009-04-09 13:54 ` Robin Getz 0 siblings, 1 reply; 28+ messages in thread From: Matt Mackall @ 2009-04-08 19:51 UTC (permalink / raw) To: Robin Getz; +Cc: netdev, linux-kernel, Chris Peterson 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 ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-08 19:51 ` Matt Mackall @ 2009-04-09 13:54 ` Robin Getz 2009-04-09 17:00 ` Matt Mackall 0 siblings, 1 reply; 28+ messages in thread From: Robin Getz @ 2009-04-09 13:54 UTC (permalink / raw) To: Matt Mackall; +Cc: netdev, linux-kernel, Chris Peterson On Wed 8 Apr 2009 15:51, Matt Mackall pondered: > On Tue, 2009-04-07 at 17:44 -0400, Robin Getz wrote: > > Is that "Everything in general, with a few exceptions", or > > "__Everything__"? > > Everything. We want every input point to better document the type of > entropy source. OK - any objections to something like this? =================================================================== --- Documentation/feature-removal-schedule.txt (revision 6236) +++ Documentation/feature-removal-schedule.txt (working copy) @@ -6,6 +6,19 @@ --------------------------- +What: IRQF_SAMPLE_RANDOM +Check: IRQF_SAMPLE_RANDOM +When: July 2009 +Why: Many of IRQF_SAMPLE_RANDOM users are technically bogus as entropy + sources in the kernel's current entropy model. To resolve this, every + input point to the kernel's entropy pool needs to better document the + type of entropy source it actually is. This will be replaced with + additional add_*_randomness functions in drivers/char/random.c + +Who: Robin Getz <rgetz@blackfin.uclinux.org> & Matt Mackall <mpm@selenic.com> + +--------------------------- + Then if someone attempts to add it, and runs checkpatch, it will generate something like: -------- ERROR: Don't use IRQF_SAMPLE_RANDOM(): see Documentation/feature-removal-schedule.txt #10: FILE: serial/bfin_5xx.c:650: + if (request_irq(uart->port.irq, bfin_serial_rx_int, IRQF_DISABLED | IRQF_SAMPLE_RANDOM, -------- My only real question is on the date... In a previous email: On Mon 6 Apr 2009 15:01, Matt Mackall pondered: > I'm eventually going to move the RNG away from the strict theoretical > entropy accounting model to a more pragmatic one which will be much > happier with iffy entropy sources, but that's a ways off. I was not sure what "a ways off" was defined as - or are the two (removal of IRQF_SAMPLE_RANDOM, and the pragmatic entropy accounting model) separate in your mind? I guess various add_*_randomness functions can be added today, and change how they are accounted for in the future? -Robin ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 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 0 siblings, 2 replies; 28+ messages in thread From: Matt Mackall @ 2009-04-09 17:00 UTC (permalink / raw) To: Robin Getz; +Cc: netdev, linux-kernel, Chris Peterson On Thu, 2009-04-09 at 09:54 -0400, Robin Getz wrote: > On Wed 8 Apr 2009 15:51, Matt Mackall pondered: > > On Tue, 2009-04-07 at 17:44 -0400, Robin Getz wrote: > > > Is that "Everything in general, with a few exceptions", or > > > "__Everything__"? > > > > Everything. We want every input point to better document the type of > > entropy source. > > OK - any objections to something like this? Hmm, this is a purely internal interface. Not sure if we need to bother with scheduling it. My plan was to simply get the new code in and sweep the kernel. -- http://selenic.com : development and support for Mercurial and Linux ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-09 17:00 ` Matt Mackall @ 2009-04-10 0:41 ` Robin Getz 2009-04-10 1:29 ` Chris Peterson 1 sibling, 0 replies; 28+ messages in thread From: Robin Getz @ 2009-04-10 0:41 UTC (permalink / raw) To: Matt Mackall; +Cc: netdev, linux-kernel, Chris Peterson On Thu 9 Apr 2009 13:00, Matt Mackall pondered: > On Thu, 2009-04-09 at 09:54 -0400, Robin Getz wrote: > > On Wed 8 Apr 2009 15:51, Matt Mackall pondered: > > > On Tue, 2009-04-07 at 17:44 -0400, Robin Getz wrote: > > > > Is that "Everything in general, with a few exceptions", or > > > > "__Everything__"? > > > > > > Everything. We want every input point to better document the type of > > > entropy source. > > > > OK - any objections to something like this? > > Hmm, this is a purely internal interface. Not sure if we need to bother > with scheduling it. My plan was to simply get the new code in and sweep > the kernel. Yeah - it just stops people from putting in more places you need to change later. ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 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 1 sibling, 1 reply; 28+ messages in thread From: Chris Peterson @ 2009-04-10 1:29 UTC (permalink / raw) To: Matt Mackall; +Cc: Robin Getz, netdev, linux-kernel > Hmm, this is a purely internal interface. Not sure if we need to bother > with scheduling it. My plan was to simply get the new code in and sweep > the kernel. Matt, sounds like you're volunteering? :) >From my understanding, the roadmap looks something like: 1. Add checkpatch warning about IRQF_SAMPLE_RANDOM 2. Add any new add_*_randomness() functions (e.g. RTC and main clocks? Serial or USB interrupts?) 3. Remove IRQF_SAMPLE_RANDOM macro (and checkpatch warning) 4. Add "pragmatic entropy accounting model"? chris ^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: IRQF_SAMPLE_RANDOM question... 2009-04-10 1:29 ` Chris Peterson @ 2009-04-10 2:27 ` Matt Mackall 0 siblings, 0 replies; 28+ messages in thread From: Matt Mackall @ 2009-04-10 2:27 UTC (permalink / raw) To: Chris Peterson; +Cc: Robin Getz, netdev, linux-kernel On Thu, 2009-04-09 at 18:29 -0700, Chris Peterson wrote: > > Hmm, this is a purely internal interface. Not sure if we need to bother > > with scheduling it. My plan was to simply get the new code in and sweep > > the kernel. > > Matt, sounds like you're volunteering? :) > > >From my understanding, the roadmap looks something like: > > 1. Add checkpatch warning about IRQF_SAMPLE_RANDOM > 2. Add any new add_*_randomness() functions (e.g. RTC and main clocks? > Serial or USB interrupts?) > 3. Remove IRQF_SAMPLE_RANDOM macro (and checkpatch warning) > 4. Add "pragmatic entropy accounting model"? Yeah, I just sat down with Ted Tso this evening and hashed out a new design. More to come. -- http://selenic.com : development and support for Mercurial and Linux ^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2009-04-10 2:29 UTC | newest] Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).