[HN Gopher] Getentropy() vs. RAND_bytes()
       ___________________________________________________________________
        
       Getentropy() vs. RAND_bytes()
        
       Author : signa11
       Score  : 8 points
       Date   : 2024-10-02 05:28 UTC (3 days ago)
        
 (HTM) web link (dotat.at)
 (TXT) w3m dump (dotat.at)
        
       | akira2501 wrote:
       | You should not be calling getentropy() often enough to be
       | concerned about it's performance. Of course RAND_bytes will be
       | faster because it doesn't have to context switch into ring 0 to
       | do the job. The vDSO feels like a complete punt by libc authors
       | on providing a sane interface to random number generation
       | particularly in threaded environments, but to be fair, POSIX
       | really is zero help here.
       | 
       | Finally if you just need to seed an RNG once in a single threaded
       | process, there's always getauxval(3) with the AT_RANDOM op,
       | combined with any number of RNGs works a real treat.
        
         | fanf2 wrote:
         | Why would I use Linux-only getauxval() when POSIX specifies a
         | reasonably portable getentropy()?
         | 
         | Your theory about the relative performance is what I thought,
         | but it turns out not to be the case for older versions of
         | OpenSSL.
         | 
         | The cover letter for getrandom() vDSO support explains the whys
         | and wherefores pretty well
         | https://lwn.net/ml/all/20240712014009.281406-1-Jason@zx2c4.c...
        
           | akira2501 wrote:
           | Auxiliary values are a part of the ELF specification.
           | 
           | Did you compare older versions of OpenSSL against the kernels
           | that were contemporary to their release dates?
           | 
           | And I read the LKML thread. In particular, I don't agree with
           | statement 2, which seems to boil down to "it's harder to get
           | right on VMs, and one time we forgot we had to special case
           | hibernation, so that serves as justification for the vDSO."
           | 
           | The notion seemingly being "we want to make it easy to write
           | carefree cryptographically secure code all managed by the
           | kernel." I think you can have two of those three but probably
           | not all three at once. What end state are we actually trying
           | to create here?
        
             | dale_glass wrote:
             | I don't see what the big deal is here? Why fight so much
             | over such a tiny patch?
             | 
             | To me this all seems like a no-brainer. A performant way to
             | do a security-critical thing with less footguns, using an
             | already existing mechanism.
        
               | akira2501 wrote:
               | I don't see what's making you interpret this as a "big
               | deal" or a "fight." This is Hacker News on a Saturday.
               | I'm offering some really light and off the cuff analysis
               | over what may potentially be a bad feature.
               | 
               | I would not consider the kernel's internal entropy
               | management a way to find "less foot guns." I don't think
               | I'm the only one who feels this way, in particular, I
               | think it's telling that the only way to form a cogent
               | argument around this feature is by invoking VMs with bad
               | vendor state management facilities.
               | 
               | Anyways.. I felt like commenting because this generally
               | feels like the "worse is actually better" trend in kernel
               | development that's become en vogue lately. I personally,
               | just don't like it, and I thought this was a forum where
               | I could just basically say that, without someone feeling
               | confronted by it.
        
       ___________________________________________________________________
       (page generated 2024-10-05 23:00 UTC)