On Mon, Aug 18, 2025 at 8:38 AM Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
>
> On Thu, Aug 14, 2025 at 3:16 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Fri, Aug 8, 2025 at 3:37 PM Jacob Champion
> > <jacob.champion@enterprisedb.com> wrote:
> >
> > > So, my next question: is getrandom() always preferable to /dev/urandom?
> >
> > I believe so. While /dev/urandom source should be kept as a fallback
> > for older kernels, we should use getrandom() if available. For
> > example, getrandom() can be used even in the face of file-descriptor
> > exhaustion and lack of access to the random devices[1]. Also, it would
> > be much faster than reading /dev/urandom as I shared the benchmark
> > result[2].
>
> Yeah. My personal reasons to be excited about it are
> 1) the newer, more sensible one-shot blocking behavior for safety, and
> 2) the ability for the OS to figure out when a virtualized environment
> has potentially "forked"
>
> So I think I would be in favor of adding this as an always-preferred
> alternative to /dev/urandom, to begin.
>
> Thinking a bit further ahead: what are some criteria we would need to
> research to decide whether getrandom() would be preferable to OpenSSL?
> Gathering a couple of considerations from upthread:
> - FIPS behavior
Do you mean random numbers generated by getrandom() complaints FIPS?
Based on my research, there doesn't appear to be any explicit
statement indicating that Linux's CSPRNG module complies with FIPS
requirements. However, there is a proposal to implement LRNG[1], which
would be FIPS-compliant. In systems that require FIPS compliance, it
seems that random numbers generated by getrandom() (or getentropy())
are typically used as a seed for FIPS-compliant random number
generators, such as OpenSSL's RAND_bytes() function.
Regards,
[1] https://lwn.net/Articles/877607/
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
