LibreSSL porting update

I've recently covered some issues with LibreSSL and some common porting mistakes.

Since these articles came out, I've noticed two broken ports I saw prior seem to have vanished. One port has seen significant improvement in response to these articles, although still has significant concerns. And worst of all, more ports are popping up.

The official team has since reiterated some of these concerns, and I also wrote two articles regarding some concerns with random data.

Unfortunately, many of these ports are continuing to rely on arc4random() implementations on certain OSs or from certain portability libraries. These OSs or libraries may be copying some or all of the code from OpenBSD, but they are not copying the implementation.

To demonstrate this, let's see how different implementations of arc4random() work across fork() using the following test code:

/*
Blogger is refusing to allow me to list the headers without trying to escape the signs.
So they are: stdio.h, stdlib.h, stdint.h, unistd.h, sys/wait.h
And on Linux: bsd/stdlib.h
*/

int main()
{
  int children = 3;
  pid_t pid = getpid();

  printf("parent process %08x: %08x %08x\n", (uint32_t)pid, arc4random(), arc4random());
  fflush(stdout);

  while (children--)
  {
    pid_t pid = fork();
    if (pid > 0) //Parent
    {
      waitpid(pid, 0, 0);
    }
    else if (pid == 0) //Child
    {
      pid = getpid();
      printf(" child process %08x: %08x %08x\n", (uint32_t)pid, arc4random(), arc4random());
      fflush(stdout);
      _exit(0);
    }
    else //Error
    {
      perror(0);
      break;
    }
  }
  printf("parent process %08x: %08x %08x\n", (uint32_t)pid, arc4random(), arc4random());
  fflush(stdout);

  return(0);
}

OpenBSD (the reference implementation):

parent process 0000660d: beb04672 aa183dd0
 child process 00001a2a: e52e0b25 764966bb
 child process 00007eb7: 27619dd1 a7c0df81
 child process 000039f5: 33daf1f1 4524c6c6
parent process 0000660d: 1eb05b45 d3956c43

Linux with libbsd 0.6:

parent process 000031cb: 2bcaaa9a 01532d3f
 child process 000031cc: 3b43383f 4fbbb4d5
 child process 000031cd: 3b43383f 4fbbb4d5
 child process 000031ce: 3b43383f 4fbbb4d5
parent process 000031cb: 3b43383f 4fbbb4d5

 NetBSD 6.1.2:

parent process 0000021a: 4bc81424 958bf90f
 child process 0000021f: c0681a36 5a3f8bdb
 child process 00000022: c0681a36 5a3f8bdb
 child process 000001fc: c0681a36 5a3f8bdb
parent process 0000021a: c0681a36 5a3f8bdb

FreeBSD 9.2:

parent process 0000032e: 03d19ad2 543c5fa4
 child process 0000032f: 6e3a1214 57b74381
 child process 00000330: 6e3a1214 57b74381
 child process 00000331: 6e3a1214 57b74381
parent process 0000032e: 6e3a1214 57b74381

DragonFlyBSD 3.4.3:

parent process 0000030a: cb987922 8f94fb58
 child process 0000030b: 65047965 1ebdc52b
 child process 0000030c: 65047965 1ebdc52b
 child process 0000030d: 65047965 1ebdc52b
parent process 0000030a: 65047965 1ebdc52b

So in looking at this data, one can see that on OpenBSD the random data is utterly different between the parent and all the various children. However, in all the ports of the function, the parent and children all share the exact same state after the fork() call. This situation is fine for single-process programs, but is a disaster in multi-process ones.

Since LibreSSL is having its random needs all being supplied by arc4random*(), and it can be used by multi-process servers, there is a serious porting problem here.

I covered this problem without elaboration in my previous article. See there for some solutions. The OpenBSD team is saying randomness is the responsibility of the OS, and for many of the issues involved, they are quite right. However, remember your ports cannot necessarily rely on the random functions provided by your OS. Even if the OSs fix them in future versions, one still has to be mindful of porting to older ones, so ensure your port doesn't rely too much on the OS.