WindfluechterNet Blog

13 thoughts on “Exim4 & Entropy”

1. We had this trouble with the GNUTLS parts of the Bongo e-mail system.

   It's not actually GNUTLS but gcrypt which causes the issue – when GNUTLS asks for random numbers, it does it through gcrypt.

   There are two parts to the problem: a. do I need random numbers? and b. do I need them from /dev/random?

   GNUTLS defaults to read from /dev/random. When no random data is available, it will block, slowing things down and/or causing mayhem. So, cutting down the use of random data is important: for example, not generating new DSA/RSA parameters on new connections, caching previous random seeds, that kind of thing.

   Second, do you need to read from /dev/random? On Linux, /dev/urandom is available and doesn't block – however, it _does_ deplete the entropy pool. You can force gcrypt to read from here, but it likely requires a patch to exim. This won't help the lack of entropy per se, but it will mean that the lack of entropy causes less problems.

   If you want to drop by #bongo on oftc sometime, I can try to help with exim if you'd like. Bongo had a lot of pain with this, I can sympathise 🙂

2. May I suggest you ask on the Debian exim users mailing list, at <http://lists.alioth.debian.org/mailman/listinfo/pkg-exim4-users>?

3. This is sadly a GNUTLS bug, see https://savannah.gnu.org/support/index.php?106112

4. Is there a way to tell exim to use /dev/urandom instead of /dev/random?

5. from our wiki (sorry, no time to translate into english):

   rng-tools

   Um sicher zu stellen das der entropy pool für exim4 immer dauerhaft gefüllt ist benutzen wir rng-tools

   aptitude install rng-tools
   echo 'RNGDOPTIONS=”-b -r /dev/urandom”' >> /etc/default/rng-tools

   Prüfen ob die Variable HRNGDEVICE in /etc/init.d/rng-tools auf eine vorhande hwrng in dev verweist

   !!Achtung!! bei backports.org Kernel >= 2.6.21-2 ist der Pfad nicht HRNGDEVICE=/dev/hwrng sondern HRNGDEVICE=/dev/.static/dev/hwrng

6. In a conversation on IRC Marc Haber said that exim4 is already /dev/urandom when there's not enough entropy in /dev/random anymore.
   So I guess this shouldn't be much of a help… but thanks for the points anyway… 🙂

7. Here's a quick translation:

   To make sure the entropy pool for exim4 never gets empty, we use the rng-tools

   aptitude install rng-tools
   echo 'RNGDOPTIONS=”-b -r /dev/urandom”' >> /etc/default/rng-tools

   Check if the HRNGDEVICE variable in /etc/init.d/rng-tools points to an existing hwrng in dev

   !!Attention!! when using backports.org kernel >= 2.6.21-2 path isn't HRNGDEVICE=/dev/hwrng but HRNGDEVICE=/dev/.static/dev/hwrng

8. Here is a script I used to use to help with building entropy. I haven't had this issue in awhile though.

   while true
   do
   entropy=$(< /proc/sys/kernel/random/entropy_avail) echo -n "$(date --iso=m) ent=$entropy act=" if [ $entropy -lt 3000 ] then echo find find / /usr /var/ /home -xdev -type f -print0 | rl -0 -c 1000 | xargs -0 cat > /dev/null
   else
   echo sleep
   sleep 10
   fi
   done

9. Just for the record:

   – the bug report against exim is closed because the original submitter vanished somehow and didn't answer the questions that were asked

   – I cannot reproduce the issue. Exim _does_ deplete entropy when building a TLS session as a server, but this process already reads from /de/urandom and does not block if entropy runs out (per man 4 random, the kernel will use a PRNG if people continue reading from /dev/urandom). I tried sending a number of 8-MB-Messages on a test system, and while this kept the entropy at a very low level, all messages went through.

   I acknowledge that exim via GnuTLS does use too much entropy, but I cannot reproduce the “cannot sent mail” issue that ij is blogging about.

10. Are you sure that the problem with large mails is to do with entropy? The entropy burned by exim is independent of the size of the e-mail, it's all consumed when the TLS session is started, so this should affect all users equally if it is to do with that.

11. I don't know, really. The users complained about not being able to send mail or get it delivered to the server otherwise.
    My own users have to use authentication and preferrably via TLS/SSL. The mail in question was such small that it shouldn't be a problem for spam scanning at SMTP data. It was only 300-400 kB in size.
    I just saw the entropy level being very low and googleing after that revealed that I wasn't the only person who experienced that behaviour.

    After all it's very sad that exim4 has those problems whereas other MTAs don't seem to suffer from this entropy issue.
    And it doesn't help the users when the switch to openssl instead of gnutls is delayed because there's still hope that gnutls upstream get this problem fixed. It hasn't done it for years, why should it now?

    I think I'll be evaluating postfix the next weeks. Mainly to get known to another MTA just for the learning effect.

12. It's not exim per se that has an issue, it's gnutls – exim in Debian is pretty much the only MTA which uses that. AIUI the gnutls use comes from licensing concerns rather than anything else…

    There used to be problems with exim becoming unable to accept new connections due to this in the past but that was due to using /dev/random and needing the entropy but as Marc said they're now using /dev/urandom so it's not an issue any more. With current stable exim can continue to accept new SSL connections happily with little or no free entropy (my own server suffers from the same entropy depletion issue, though it has no appreciable effect on operation).

13. > The users complained about not being able to send mail or get it delivered to the server otherwise.

    This is, unfortunately, completely unuseable information. If you want me to spend time on the issue, pretty PLEASE help reproducing the issue. A bug that cannot be reproduced does not exist and cannot be fixed.

Comments are closed.