Modify

Opened 7 years ago

Closed 4 years ago

Last modified 4 years ago

#9631 closed enhancement (fixed)

Increase entropy sources for ar71xx devices

Reported by: anonymous Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: base system Version: Trunk
Keywords: Cc:

Description

It looks like
cat /proc/sys/kernel/random/entropy_avail
always return near 0 values even after hours of runtime.

Since it looks like interrupts could be the only source of entropy available for these routers please have network IRQs help entropy pool

Attachments (0)

Change History (27)

comment:1 Changed 6 years ago by Jonathan Bennett <jbscience87@…>

I can confirm that this is a problem on the TP-link WA901nd v2 in latest trunk.
It's also happening on a tp-link WR841n running a recent trunk (28007).
cat /dev/random hangs indefinitely.

It's also causing hostapd to continually add randomness.

I have a tp-link wr1043n that does not show this problem. It has a reasonable pool of randomness. It is running 10.03.1-rc3.

This behavior is a regression, then, it seems.

comment:2 Changed 6 years ago by candrews@…

It seems that hostapd will hang without enough entropy. I believe this is why I cannot associate unless I delete /dev/random and replace it with a symlink to /dev/urandom (which I know is bad).

comment:3 Changed 6 years ago by hnyman

I just tested with my trunk build (28140) for WNDR3700, and the cat /dev/random seems to hang. /dev/urandom seems to work.

comment:4 Changed 6 years ago by hnyman

I have a tp-link wr1043n that does not show this problem. It has a reasonable pool of randomness. It is running 10.03.1-rc3.

The regression is probably due to r23982 (done after rc3), which removed the network device driver as an interrupt entropy source.

There was quite much discussion in the Linux development community in 2008-2009 about removing network drivers as randomness sources, as theoretically somebody might figure out a way to affect the generated randomness through them (by sending carefully timed packets). Majority of the developers decided to remove network drivers from random pool, and the r23982 is probably a delayed application of that design principle. (see discussion e.g. at http://thread.gmane.org/gmane.linux.kernel/680723 , https://lkml.org/lkml/2009/4/6/283 )

However, typical Openwrt devices are headless, no video, no audio, no keyboard, so there aren't any "real user entropy" sources, which are supposed serve as the replacement. Removing the network driver as source without creating a replacement source is real problematic.

I am considering re-enabling that r23982 in my own build, and checking the impact of that in the randomness pool (and the /dev/random device).

Even if that is not accepted as a general way, the devs should then

comment:5 Changed 6 years ago by hnyman <hannu.nyman@…>

I searched a bit in the net about possible tools to add entropy.

One such tool is rngd daemon included in the rng-tools package from http://sourceforge.net/projects/gkernel/ . Manual: http://linux.die.net/man/8/rngd

The tool can be used to add entropy to the kernel's entropy pool either from some genuine hardware-based entropy source, or as a quick&dirty patch also from /dev/urandom. Using urandom isn't a perfect solution, but it will satisfy those applications looking for input from /dev/random.

As far as I found out, nobody had complied the rngd package for Openwrt, so far. So, I made a try out of it, and succeeded both for Backfire and trunk.

I defined a package that downloads the sources from SF. (This is my first package definition, so the dependencies and conventions might not be quite correct, but the package seems to work.)

Hopefully somebody can figure out a way to connect some real entropy source in ar71xxx devices through this daemon.

Package definition:

Index: /Openwrt/backfire/feeds/packages/utils/rng-tools/Makefile
===================================================================
--- /Openwrt/backfire/feeds/packages/utils/rng-tools/Makefile	(revision 0)
+++ /Openwrt/backfire/feeds/packages/utils/rng-tools/Makefile	(revision 0)
@@ -0,0 +1,35 @@
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=rng-tools
+PKG_VERSION:=3
+PKG_RELEASE:=1
+
+PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
+PKG_SOURCE_URL:=http://downloads.sourceforge.net/project/gkernel/rng-tools/3/
+PKG_MD5SUM:=fa305916ec101c85c0065aeceb81a38d
+
+PKG_FIXUP:=libtool
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/rng-tools
+  SECTION:=utils
+  CATEGORY:=Utilities
+  DEPENDS:=+USE_UCLIBC:argp-standalone
+  TITLE:=Daemon for adding entropy to kernel entropy pool
+  URL:=http://sourceforge.net/projects/gkernel/
+endef
+
+ifdef CONFIG_USE_UCLIBC
+CONFIGURE_VARS += \
+	LIBS="-largp"
+endif
+
+define Package/rng-tools/install
+	$(INSTALL_DIR) $(1)/usr/bin
+	$(INSTALL_BIN) $(PKG_BUILD_DIR)/rngtest $(1)/usr/bin/
+	$(INSTALL_DIR) $(1)/sbin
+	$(INSTALL_BIN) $(PKG_BUILD_DIR)/rngd $(1)/sbin/
+endef
+
+$(eval $(call BuildPackage,rng-tools))

Output of test run in Backfire:

BusyBox v1.15.3 (2011-09-07 23:41:00 EEST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 Backfire (10.03.1-RC6, r28191) --------------------
  * 1/3 shot Kahlua    In a shot glass, layer Kahlua
  * 1/3 shot Bailey's  on the bottom, then Bailey's,
  * 1/3 shot Vodka     then Vodka.
 ---------------------------------------------------
root@OpenWrt:~# ls -l /sbin/rngd
-rwxr-xr-x    1 root     root        40000 Sep  7 23:44 /sbin/rngd
root@OpenWrt:~# ls -l /usr/bin/rngtest
-rwxr-xr-x    1 root     root        43236 Sep  7 23:44 /usr/bin/rngtest
root@OpenWrt:~# cd /etc/config
root@OpenWrt:/etc/config# ./query_random_avail.sh
Thu Sep 8 00:08:05 EEST 2011 entropy_avail is 44
Thu Sep 8 00:08:10 EEST 2011 entropy_avail is 44
Thu Sep 8 00:08:15 EEST 2011 entropy_avail is 44
Thu Sep 8 00:08:20 EEST 2011 entropy_avail is 44
Thu Sep 8 00:08:25 EEST 2011 entropy_avail is 44
Thu Sep 8 00:08:30 EEST 2011 entropy_avail is 44
Thu Sep 8 00:08:35 EEST 2011 entropy_avail is 44
^C
root@OpenWrt:/etc/config# rngd -r /dev/urandom -W 4096 -t 30
root@OpenWrt:/etc/config# ./query_random_avail.sh
Thu Sep 8 00:08:46 EEST 2011 entropy_avail is 3712
Thu Sep 8 00:08:51 EEST 2011 entropy_avail is 3328
Thu Sep 8 00:08:56 EEST 2011 entropy_avail is 2944
Thu Sep 8 00:09:01 EEST 2011 entropy_avail is 2560
Thu Sep 8 00:09:06 EEST 2011 entropy_avail is 2176
Thu Sep 8 00:09:11 EEST 2011 entropy_avail is 1792
Thu Sep 8 00:09:16 EEST 2011 entropy_avail is 3840
Thu Sep 8 00:09:21 EEST 2011 entropy_avail is 3456
Thu Sep 8 00:09:26 EEST 2011 entropy_avail is 2688
Thu Sep 8 00:09:31 EEST 2011 entropy_avail is 2304
Thu Sep 8 00:09:36 EEST 2011 entropy_avail is 1920
Thu Sep 8 00:09:41 EEST 2011 entropy_avail is 1536
Thu Sep 8 00:09:46 EEST 2011 entropy_avail is 3840
Thu Sep 8 00:09:51 EEST 2011 entropy_avail is 3456
^C

So, using the daemon clearly increases the apparent entropy pool, although that randomness is merely sourced from /dev/urandom, and is not genuine user/hardware-event based entropy.

The script used for reading the available bits every 5 seconds:

#!/bin/ash
while (true)
do
  echo `date` entropy_avail is `cat /proc/sys/kernel/random/entropy_avail`
  sleep 5
done

comment:6 Changed 6 years ago by dimitris@…

(typepad didn't like my first submission, hope this works)

The Entropy Key might be another possibility. Trunk's kernel-space seems to work after kmod-usb-acm is installed:

usbcore: registered new interface driver cdc_acm
cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters
usb 2-1: new full speed USB device number 3 using ar71xx-ohci
cdc_acm 2-1:1.0: This device cannot do calls on its own. It is not a modem.
cdc_acm 2-1:1.0: ttyACM0: USB ACM device
root@maytag:~# ls -l /dev/ttyACM0 
crw-rw-rw-    1 root     root      166,   0 Sep  8 21:50 /dev/ttyACM0

I have some (limited) time so I'll try to create a package for the associated user-space software. FWIW the USB stick doesn't have to be attached to the router box, that's just my own preferred deployment mode. The alternative is to deploy an entropy server that can feed entropy to multiple clients over the network. In either case the init sequence should be such that entropy is available before services that need it (dropbear, hostapd etc) are started.

comment:7 Changed 6 years ago by anonymous

For those interested: the rng-tools package has now been added to the trunk packages repository with r28332. It can be found in trunk menuconfig from the Utilities section.

comment:8 follow-up: Changed 6 years ago by anonymous

As of the latest trunk, rng-tools has a dependency on argp-standalone which is nowhere to be found, so the rng-tools package is completely useless, just thought you should know.

comment:9 in reply to: ↑ 8 Changed 6 years ago by hnyman <hannu.nyman@…>

Replying to anonymous:

As of the latest trunk, rng-tools has a dependency on argp-standalone which is nowhere to be found, so the rng-tools package is completely useless, just thought you should know.

rng-tools compiles just fine with current trunk source code (29844). So, the package works at least if you build it along the firmware.

comment:10 Changed 6 years ago by igor

You can compile it separately and install with --force-depends.

comment:11 Changed 6 years ago by nicoduck

Do you think using rngd with /dev/random is better that using the network driver as an entropy source?
For me it sounds even worse :-(

comment:12 Changed 5 years ago by hnyman <hannu.nyman@…>

I am currently using "haveged" as the entropy source. It is available in the Utilities section in menuconfig since r31161.

Another alternative approach is now mentioned in #11951.


Looks like Spambayes is angry. Lets add some garbage here to lower the score and get this accepted...

comment:13 follow-up: Changed 5 years ago by Craig <candrews@…>

This LWN article seems very much relevant: https://lwn.net/Articles/507115/

An OpenWRT developer may want to track the status of those patches, and perhaps apply them to OpenWRT now, as they seem to solve this lack of entropy problem in a nice way.

comment:14 in reply to: ↑ 13 Changed 5 years ago by anonymous

Replying to Craig <candrews@…>:

This LWN article seems very much relevant: https://lwn.net/Articles/507115/

An OpenWRT developer may want to track the status of those patches, and perhaps apply them to OpenWRT now, as they seem to solve this lack of entropy problem in a nice way.

ticket #11951 has a backport for trunk

comment:15 Changed 5 years ago by florian

  • Resolution set to fixed
  • Status changed from new to closed

Fixed with r33559

comment:16 Changed 5 years ago by mmitar@…

Hm, r33559 still does not return back getting entropy from the network devices? Especially on WiFi nodes with wireless devices it would be great if it would be possible to capture entropy from packets flowing by the WiFi card even without configuring the device, so that you can generate keys before bringing up the network.

Currently OpenWrt generates SSH keys on first boot. How much entropy does system really has at that point?

comment:17 Changed 5 years ago by mmitar@…

It should be at least a image compile time switch to take entropy from the network interface.

comment:18 Changed 5 years ago by alex_y_xu@…

Is it reasonable to use the radio (presumably available on all routers with this issue) to obtain entropy?

comment:19 Changed 5 years ago by mmitar@…

The main issue I see is SSH key generation at first boot. We have to assure that keys had enough entropy. And I am not sure if WiFi drivers are already loaded and interfaces configured at that point?

comment:20 Changed 5 years ago by hojuruku@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

I don't see this fixed in trunk on tp-link wl941nd-v3

See my comments on the forum.
http://forum.openwrt.org/viewtopic.php?pid=194923#p194923

comment:21 Changed 4 years ago by rhill@…

Above whatever else solution, how about a config file which content is filled by the user at setup as an extra first step to feed the entropy pool? (with appropriate setup gui in luci)

If all else fail, it's comforting for the admin to know that the random generator is fed with his own high-entropy sequence of bits.

comment:22 Changed 4 years ago by Iosif Peterfi <iosif.peterfi@…>

Haveged is available in OpenWRT.

https://dev.openwrt.org/browser/packages/utils/haveged

What is left to do is integrate it with the dropbear startup script as in:

make sure haveged starts before dropbear by editing haveged.init
make sure dropbear will sleep for like 10 seconds in order to have enough entropy in the keygen procedure by editing dropbear.init

This should give enough entropy for dropbear keygen.

Let me know if you guys are interested in a patch.

comment:23 Changed 4 years ago by Mitar

Are you sure haveged improves situation on embedded devices? The issue I see is that it relays on multitasking between processes, but embedded devices mostly have a fixed set of daemons which run, so while there is still entropy, it is much less than what it could. How exactly does haveged evaluate that it is getting relevant entropy?

I would still vote for simple patch which would use network and WiFi interface for entropy source. This is for routers probably the most natural source of entropy.

comment:24 follow-up: Changed 4 years ago by anonymous

Ahoi everyone,

it was requested on IRC that I send my solution to the entropy problem with the current
kernel (e.g. having 0 available entropy):

root@OpenWrt:/# cat /proc/sys/kernel/random/entropy_avail
0

In the build root I've patched

build_dir/linux-ar71xx_nand/linux-3.3.8/arch/mips/include/asm/timex.h

--- timex.h?id=refs%2Ftags%2Fv3.3.8 2013-10-17 17:23:12.000000000 +0200
+++ timex.h 2013-10-17 17:07:59.888938183 +0200
@@ -35,7 +35,13 @@

static inline cycles_t get_cycles(void)
{

  • return 0;

+
+ if (cpu_has_counter) {
+ return read_c0_count();
+ }
+ else {
+ return 0; /* no usable counter */
+ }

}

#endif /* KERNEL */

After applying and rebuilding the kernel:

root@OpenWrt:/# cat /proc/sys/kernel/random/entropy_avail
162

This was tested on mips32r2/24kc (Mikrotik Routerboard 450G) but it might work
for others as well. Until this is fixed upstream and openwrt follows up with
the kernel, it might be an easy fix for some people in order to have better
entropy for SSL/VPN.

Hopefully it will be useful to someone,

chrono

comment:25 in reply to: ↑ 24 Changed 4 years ago by anonymous

here is the diff again in functional :)

--- timex.h?id=refs%2Ftags%2Fv3.3.8     2013-10-17 17:23:12.000000000 +0200
+++ timex.h     2013-10-17 17:07:59.888938183 +0200
@@ -35,7 +35,13 @@

 static inline cycles_t get_cycles(void)
 {
-       return 0;
+
+       if (cpu_has_counter) {
+               return read_c0_count();
+       }
+       else {
+               return 0;       /* no usable counter */
+       }
 }

 #endif /* __KERNEL__ */

comment:26 Changed 4 years ago by nbd

  • Resolution set to fixed
  • Status changed from reopened to closed

as of r38486, the router mixes in some randomness from ath9k

comment:27 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.