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
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
On Mon, 06 Apr 2009 14:40:05 -0400
Jeff Garzik <[email protected]> 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.
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
On Mon, 6 Apr 2009 14:30:26 -0400
Robin Getz <[email protected]> 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
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
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
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...
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
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
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
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
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.
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
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().
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
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
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
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().
----- Original Message -----
From: "Robin Getz" <[email protected]>
To: "Chris Peterson" <[email protected]>
Cc: "Matt Mackall" <[email protected]>; <[email protected]>;
<[email protected]>
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
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
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
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
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 <[email protected]> & Matt Mackall
<[email protected]>
+
+---------------------------
+
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
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
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.
> 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
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