Hello David. David Čepelík <[email protected]> wrote: |I suspect I have found a bug in s-nail/s-mailx.
Hmmm. |When trying to send mail using | | echo test | mail -stest david | |the mail command would block indefinitely. The same |happens when trying to read local mail. | |I cloned https://git.sdaoden.eu/scm/s-nail.git and |built the `devel' target, then run s-nail in gdb. |The backtrace shown by gdb upon killing the process |is attached. | |I managed to fix the build by #undef-ing HAVE_GETRANDOM |in auxlily.c:60. Then, n_msleep is not called and the |application works as usual. | |I'm running Arch Linux, pacman -Q | grep s-nail shows | | s-nail 14.9.3-1 | |The system is a virtualized VPS running OpenVZ, if I |remember correctly---just in case this matters. | |If I can help to fix the problem or provide further |information, let me know. This is a mysterious thing you report, but it rather sounds like a bug in either GLibC or the Linux Kernel. I admit the code is not very nice, but we call getrandom(2) in blocking mode and request exactly the amount of bytes (the manual says " If the urandom source has been initialized, reads of up to 256 bytes will always return as many bytes as requested and will not be interrupted by signals. So looping as such could be seen as an error, since the above guarantees we will get what we want. On the other hand i have written this before getrandom(3) has entered the GLibC (we can use the systemcall; and even though by accident i have recognized it via lkml.org i think once that thing entered that C library i have not looked at the patch, and, forgive me please, i have never been able to find my way through that jungle that is called GNU C library), and who knows, who knows, you know, i _know_ signal handling is messy. Note the manual also says The user of getrandom() must always check the return value, to determine whether either an error occurred or fewer bytes than requested were returned. In the case where GRND_RANDOM is not specified and buflen is less than or equal to 256, a return of fewer bytes than requested should never happen, but the careful programmer will check for this anyway! But maybe it would be better to increment the pointer a.k.a. support sequential filling of our buffer, that is an absolutely correct observation! I will do this in a minute, since i also have been, well, "forced" is a wording too strong, to simply use RAND_bytes(3) of the OpenSSL library when we link against that one anyway -- today! So yes, thanks for reporting this! |The system is a virtualized VPS running OpenVZ, if I |remember correctly---just in case this matters. Well, i do not think it should, our little user-space program should simply block and hang around until the entropy is seeded. It should not even sleep, thus my initial statement above. But this can actually be quite late in a Linux VM indeed! Maybe there should be an error message?! Doing that! Again, a future version of S-nail (under ArchLinux) will (likely) use RAND_bytes(3), and there we have ~/.rnd (or the file backed by *ssl-rand-file*), and if that fails to seed OpenSSL, we will instead panic the program! On the other hand it allows to do $ dd if=/dev/urandom of=~/.rnd bs=1024 count=1 in a proper system state (or on a different system which has that), and from then on you are on the safe side, whatever happens. But hey, maybe it is possible to feed the /dev/TTY with a large number of random bytes, and increase the Linux entropy like that in that VM?? I never tried it, and i have no idea which entropy sources that OpenVZ container and/or the Linux kernel has. Is this a satisfying answer? Ciao, David, --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
