This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Why is getentropy marked with warn_unused_result?


On Fri, Jul 28, 2017 at 8:16 AM, Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
> On 27/07/2017 21:12, Joseph Myers wrote:
>> On Sun, 23 Jul 2017, Florian Weimer wrote:
>>
>>> I'm still open to implementing emulation within glibc if problems like
>>> these convince the glibc community that this is necessary.
>>
>> I don't object to a straightforward emulation that opens /dev/urandom with
>> O_CLOEXEC, does the read and closes the file, each time getentropy is
>> called (if __NR_getrandom is not defined, or if the getrandom syscall
>> returns an ENOSYS error).  The argument for emulation in getentropy is
>> stronger than that for emulating the lower-level getrandom interface.
>>
>
> If I recall correctly (and the summary at [1] helped as well), the main
> issue with the getentropy emulation is how to handle correctly any file
> operation issue (non existent urandom file for some reason, EMFILE/ENFILE,
> ENOMEM) which leads to different function semantic whether the emulation
> is used.

I haven't put a lot of thought into this, but it seems probably safest
to map all such errors to ENOSYS, which applications (hopefully)
already know they have to check for.  People trying to figure out
what's really going on can always break out the strace.

I agree that the right place for emulation is getentropy, as it is the
portable interface.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]