5 ms·

Can we, please, have a syscall in Linux that returns random bytes from the system CSPRNG or blocks if not seeded yet and doesn't involve dealing with file descr

Can we, please, have a syscall in Linux that returns random bytes from the system CSPRNG or blocks if not seeded yet and doesn't involve dealing with file descriptors? But even while one isn't available, why is LibreSSL trying to use a userland CSPRNG instead of always reading from /dev/urandom and aborting when that fails?

AlyssaRowan 12y ago
Yes. Actually, the relevant IETF list is now calling for that: Linux needs getentropy(2). I may cook up my own and submit it to LKML, or perhaps someone else can, but there's no way out of this one without kernel support. I don't know why the rest of the function even exists. It's the kind of cruft libReSSL is trying to get rid of. I am not entirely sure a PRNG should even exist in the library, and personally, I'd pass it onto /dev/urandom or /dev/random or the relevant syscall. I agree with making it (154-156) a hard kill for a TLS library not to be able to get entropy. And, this is great! This is exactly the kind of thing we're able to find now that some of the code isn't a hedge-maze.
- agwa 12y ago
  Yeah, if LibreSSL continues to implement its own PRNG in userspace, a getentropy syscall only solves the chroot issue, not the fork issue. You're probably right that a PRNG should not exist in the library.
- quotemstr 12y ago
  > there's no way out of this one without kernel support This problem is due to LibreSSL's internal architecture being too closely matched to OpenBSD, not a fundamental problem with Linux.
- vidarh 12y ago
  The comments in the code makes it exceedingly clear that a part of the reason for this code to exist is to make a point, and it seems they've succeeded very well at that.
- lomnakkus 12y ago
  Please do submit it. Bonus points if you can make it work like BSD's random/urandom, i.e. block until the entropy estimator says "OK, it's secure to use now", but never block thereafter. EDIT to add: Frankly, it's a disgrace that Linux doesn't already do this, instead choosing to push the burden of getting all the details right to userspace where you can be vulnerable to all sorts of interesting timing attacks, FD-based DoS, etc.
- AlyssaRowan 12y ago
  Just adding a link to the IETF discussion thread here (and yes, that's really what the randomness list is called!): https://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/msg00119.html https://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/ms... Theodore T'so isn't completely opposed to the idea, it seems.
ot 12y ago
What are the advantages of a syscall in place of /dev/urandom?
- adobriyan 12y ago
  Less syscalls.
  - quotemstr 12y ago
    No. read(2) is one syscall, and the cost of the initial open is negligible. One real motivation seems to be wanting programs to work without a /dev. I don't think that's a reasonable requirement.
    - vidarh 12y ago
      Access to /dev is DOS'able in many situations by exhausting file descriptor / open files limits.
      - quotemstr 12y ago
        > Access to /dev is DOS'able in many situations by exhausting file descriptor / open files limits. That's why you open /dev/urandom in advance of performing operations that require randomness. If that open fails, you don't go on to perform the operation that requires randomness.
        vidarh 12y ago
        Even if you have opened it, you have no guarantee that the file descriptor has not been closed since. Yes, that would be stupid of the user of the library, but many security lapses happens because people makes stupid assumptions. Code to close all file descriptors on fork for example is fairly common, so you can not safely assume that the file descriptor remains valid.
        quotemstr 12y ago

AlyssaRowan 12y ago

Yes. Actually, the relevant IETF list is now calling for that: Linux needs getentropy(2). I may cook up my own and submit it to LKML, or perhaps someone else can, but there's no way out of this one without kernel support. I don't know why the rest of the function even exists. It's the kind of cruft libReSSL is trying to get rid of. I am not entirely sure a PRNG should even exist in the library, and personally, I'd pass it onto /dev/urandom or /dev/random or the relevant syscall. I agree with making it (154-156) a hard kill for a TLS library not to be able to get entropy. And, this is great! This is exactly the kind of thing we're able to find now that some of the code isn't a hedge-maze.

agwa 12y ago
Yeah, if LibreSSL continues to implement its own PRNG in userspace, a getentropy syscall only solves the chroot issue, not the fork issue. You're probably right that a PRNG should not exist in the library.
quotemstr 12y ago
> there's no way out of this one without kernel support This problem is due to LibreSSL's internal architecture being too closely matched to OpenBSD, not a fundamental problem with Linux.
vidarh 12y ago
The comments in the code makes it exceedingly clear that a part of the reason for this code to exist is to make a point, and it seems they've succeeded very well at that.
lomnakkus 12y ago
Please do submit it. Bonus points if you can make it work like BSD's random/urandom, i.e. block until the entropy estimator says "OK, it's secure to use now", but never block thereafter. EDIT to add: Frankly, it's a disgrace that Linux doesn't already do this, instead choosing to push the burden of getting all the details right to userspace where you can be vulnerable to all sorts of interesting timing attacks, FD-based DoS, etc.
AlyssaRowan 12y ago
Just adding a link to the IETF discussion thread here (and yes, that's really what the randomness list is called!): https://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/msg00119.html https://www.ietf.org/mail-archive/web/dsfjdssdfsd/current/ms... Theodore T'so isn't completely opposed to the idea, it seems.

ot 12y ago

What are the advantages of a syscall in place of /dev/urandom?

adobriyan 12y ago
Less syscalls.
- quotemstr 12y ago
  No. read(2) is one syscall, and the cost of the initial open is negligible. One real motivation seems to be wanting programs to work without a /dev. I don't think that's a reasonable requirement.
  - vidarh 12y ago
    Access to /dev is DOS'able in many situations by exhausting file descriptor / open files limits.
    - quotemstr 12y ago
      > Access to /dev is DOS'able in many situations by exhausting file descriptor / open files limits. That's why you open /dev/urandom in advance of performing operations that require randomness. If that open fails, you don't go on to perform the operation that requires randomness.
      - vidarh 12y ago
        Even if you have opened it, you have no guarantee that the file descriptor has not been closed since. Yes, that would be stupid of the user of the library, but many security lapses happens because people makes stupid assumptions. Code to close all file descriptors on fork for example is fairly common, so you can not safely assume that the file descriptor remains valid.
        quotemstr 12y ago