IRQF_SAMPLE_RANDOM question...

IRQF_SAMPLE_RANDOM question...

[Robin Getz]

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

Re: IRQF_SAMPLE_RANDOM question...

[Jeff Garzik]

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

Re: IRQF_SAMPLE_RANDOM question...

[Stephen Hemminger]

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.

Re: IRQF_SAMPLE_RANDOM question...

[Jeff Garzik]

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

Re: IRQF_SAMPLE_RANDOM question...

[Alan Cox]

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

Re: IRQF_SAMPLE_RANDOM question...

[Matt Mackall]

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

Re: IRQF_SAMPLE_RANDOM question...

[Robin Getz]

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

Re: IRQF_SAMPLE_RANDOM question...

[Sven-Haegar Koch]

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...

Re: IRQF_SAMPLE_RANDOM question...

[Jeff Garzik]

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

Re: IRQF_SAMPLE_RANDOM question...

[Matt Mackall]

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

Re: IRQF_SAMPLE_RANDOM question...

[Jeff Garzik]

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

Re: IRQF_SAMPLE_RANDOM question...

[Jeremy Fitzhardinge]

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

Re: IRQF_SAMPLE_RANDOM question...

[Robin Getz]

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.

Re: IRQF_SAMPLE_RANDOM question...

[Matt Mackall]

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

Re: IRQF_SAMPLE_RANDOM question...

[Chris Peterson]

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().

Re: IRQF_SAMPLE_RANDOM question...

[Robin Getz]

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

Re: IRQF_SAMPLE_RANDOM question...

[Robin Getz]

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

Re: IRQF_SAMPLE_RANDOM question...

[Jeff Garzik]

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

Re: IRQF_SAMPLE_RANDOM question...

[Robin Getz]

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().

Re: IRQF_SAMPLE_RANDOM question...

[Matt Mackall]

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

Re: IRQF_SAMPLE_RANDOM question...

[Gilles Espinasse]

----- 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

Re: IRQF_SAMPLE_RANDOM question...

[Chris Friesen]

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

Re: IRQF_SAMPLE_RANDOM question...

[Robin Getz]

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

Re: IRQF_SAMPLE_RANDOM question...

[Robin Getz]

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

Re: IRQF_SAMPLE_RANDOM question...

[Matt Mackall]

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

Re: IRQF_SAMPLE_RANDOM question...

[Robin Getz]

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.

Re: IRQF_SAMPLE_RANDOM question...

[Chris Peterson]

> 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

Re: IRQF_SAMPLE_RANDOM question...

[Matt Mackall]

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