Re: Why is getentropy marked with warn_unused_result?

[Florian Weimer <fw at deneb dot enyo dot de>]

* Florian Bruhin:

> I posted to libc-help, not sure if it was intended that the answer got
> to libc-alpha - I re-added libc-help now.
>
> Here is my original message:
> https://sourceware.org/ml/libc-help/2017-07/msg00020.html
>
> And here are the current sources:
> https://github.com/qt/qtbase/blob/9ca3443a37284bedaf74475c26af173b00757178/src/corelib/global/qrandom.cpp#L123-L134

  // getentropy can read at most 256 bytes, so break the reading
  qssize_t read = 0;
  while (count - read > 256) {
    // getentropy can't fail under normal circumstances
    read += getentropy(reinterpret_cast<uchar *>(buffer) + read, 256);
  }

Okay, that assumption is just wrong on GNU/Linux.

> FWIW looks like Qt is adding an assertion now:
> https://codereview.qt-project.org/#/c/200161/
>
> But Thiago Macieira says there:
>
>     We don't accept ENOSYS. If you're using a glibc new enough to have
>     the getentropy() function (2.25), then your kernel should be new
>     enough (> 3.17). This is also recorded in the ELF note section
>     indicating that we need kernel 3.17.

Wow, that's a bit drastic.

>     $ file lib/libQt5Core.t.so.5.10.0 
>     lib/libQt5Core.t.so.5.10.0: ELF 64-bit LSB shared object, x86-64,
>     version 1 (SYSV), dynamically linked, interpreter
>     /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.17.0,
>     BuildID[sha1]=2cf147fe0b09697860b702f833acde6c0f7e039d, with
>     debug_info, not stripped

That's going to cause unnecessary load failures because many
distribution kernels backport the getrandom system call to earlier
kernels.

I'm still open to implementing emulation within glibc if problems like
these convince the glibc community that this is necessary.