crypto/rand: use getentropy(2) on OpenBSD

[mmcco]

It's the progenitor of Linux's getrandom(2), which Go already supports. I have a patch that works on AMD64. I won't submit a pull request until it's tested on i386 and ARM (help welcome!).

This generally just involves mirroring the approach used for getrandom(2). However, we don't need to test for availability, as all supported OpenBSD releases have getentropy(2). The only other caveat is that I had to add syscall.Syscall2() for OpenBSD, as getentropy(2) takes two arguments.

The interface is very simple - here's the man page.

It's a pretty straightforward change. I just wanted to mention it as early as possible, as per the Contribution Guidelines.

Thoughts?

[mdempsky]

Changing internal/syscall/unix to utilize getentropy() on OpenBSD sounds reasonable to me.

It won't be added to package syscall though (which is frozen), and I don't see a need to add it to golang.org/x/sys/unix either, since Linux's getrandom() isn't available there either.

There's no need to add syscall.Syscall2. You can use syscall.Syscall and just pass 0 as a dummy third argument.

Don't send a Github pull request. Upload a CL to Gerrit, like the Contribution Guidelines explain. (But expect to wait until after 1.6 is released for it to be reviewed.)

[minux]

You don't need to add syscall.Syscall2, just use syscall.Syscall with zero as the 3rd syscall argument. Adding it to internal/syscall/unix so that crypto/rand automatically use it sounds good to me.

[bradfitz]

SGTM too, putting it in internal/syscall/unix next to the Linux getrandom stuff.

[gopherbot]

CL https://golang.org/cl/18219 mentions this issue.

[mmcco]

Based on the syscall traces I'm seeing, it seems that I misinterpreted the logic in crypto/rand. How should I change it so that getentropy(2) is only used to seed the CSPRNG rather than being called directly? This is how the syscall is intended to be used.

[minux]

I don't think we have a CSPRNG in crypto/rand, all reads are serviced from OS specific CSPRNG.

[mmcco]

@minux I think there is a CSPRNG - see src/crypto/rand/rand_unix.go:85.

However, altGetRandom sources such as Linux's getrandom(2) are used directly rather than fed through the CSPRNG. This may not be the best choice from a performance and reliability perspective. I'd be interested to hear more about the tradeoffs to consider in Go specifically. Most C crypto guides I've read suggest that mature applications use userland CSPRNGs that are seeded with OS-supplied entropy sources rather than using data directly from the OS sources.

I've drafted a patch that uses OpenBSD's getentropy(2) through the CSPRNG rather than querying it directly. I'll share once I've verified this with ktrace(1) and kdump(1).

[mdempsky]

@mmcco If you want to propose that crypto/rand feed the kernel entropy source through another userspace CSPRNG, I suggest you do that as a separate issue. I'm not convinced that should be tied to whether crypto/rand uses getentropy on OpenBSD.

[minux]

That alternative CSPRNG is only intended for system without a reliable /dev/urandom (only Plan 9). I agree with mdempsky that if we decide to seed the alternative CSPRNG with kernel provided seeds, we should do that in a separate CL.

[mmcco]

@mdempsky:

I'm not convinced that should be tied to whether crypto/rand uses getentropy on OpenBSD.

The creators of getentropy frequently specify that it is intended to be used for seeding, not for direct randomness access. I can try to get more information on why this is the case, although I've mentioned a few probable reasons above.

I think there's a chance of a slight misunderstanding, though, based on your wording:

If you want to propose that crypto/rand feed the kernel entropy source through another userspace CSPRNG, I suggest you do that as a separate issue.

What is meant by "another" here? If you're referring to getentropy as a userland CSPRNG, remember: it's a system call directly to the kernel.

[mmcco]

That said, I'm not opposed to opening a second CL.