[#87467] [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError — mofezilla@...
Issue #14841 has been reported by hirura (Hiroyuki URANISHI).
3 messages
2018/06/10
[#87515] [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError — hirura@...
Issue #14841 has been updated by hirura (Hiroyuki URANISHI).
7 messages
2018/06/19
[#87516] Re: [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError
— Eric Wong <normalperson@...>
2018/06/19
hirura@gmail.com wrote:
[#87517] Re: [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError
— Eric Wong <normalperson@...>
2018/06/19
Sorry, I left this out: If you can reproduce it again, can you
[#87519] Re: [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError
— hirura <hirura@...>
2018/06/19
Hi Eric,
[#87521] Re: [Ruby trunk Bug#14841] Very rarely IO#readpartial does not raise EOFError
— Eric Wong <normalperson@...>
2018/06/19
hirura <hirura@gmail.com> wrote:
[#87541] [Ruby trunk Feature#14859] [PATCH] implement Timeout in VM — normalperson@...
Issue #14859 has been reported by normalperson (Eric Wong).
4 messages
2018/06/21
[#87570] [Ruby trunk Feature#14859] [PATCH] implement Timeout in VM — eregontp@...
Issue #14859 has been updated by Eregon (Benoit Daloze).
4 messages
2018/06/21
[#87605] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — takashikkbn@...
Issue #14867 has been reported by k0kubun (Takashi Kokubun).
3 messages
2018/06/23
[#87614] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — normalperson@...
Issue #14867 has been updated by normalperson (Eric Wong).
4 messages
2018/06/23
[#87631] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — takashikkbn@...
Issue #14867 has been updated by k0kubun (Takashi Kokubun).
5 messages
2018/06/25
[#87635] Re: [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process
— Eric Wong <normalperson@...>
2018/06/25
takashikkbn@gmail.com wrote:
[#87665] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — eregontp@...
Issue #14867 has been updated by Eregon (Benoit Daloze).
4 messages
2018/06/28
[#87710] [Ruby trunk Bug#14867] Process.wait can wait for MJIT compiler process — Greg.mpls@...
Issue #14867 has been updated by MSP-Greg (Greg L).
3 messages
2018/06/30
[ruby-core:87476] [Ruby trunk Bug#14837] ruby blocks due to unavoidable getrandom without GRND_NONBLOCK
From:
kevin@...
Date:
2018-06-11 17:53:58 UTC
List:
ruby-core #87476
Issue #14837 has been updated by kevinoid (Kevin Locke).
After re-reading the diff more closely I realized I had misunderstood. As I now understand, r63624 has the effect of adding `GRND_NONBLOCK` for `Random.new_seed` and the internal seeds and removing it for `Random.urandom`, which is probably what was originally intended in r52808. Seems like a good fix to me. The only potential issue I can see is that the internal seed is used to protect against hash table algorithmic complexity attacks (see r17465) so it might be possible to attack programs started before the system gains sufficient entropy to be unpredictable.
Thanks again!
----------------------------------------
Bug #14837: ruby blocks due to unavoidable getrandom without GRND_NONBLOCK
https://bugs.ruby-lang.org/issues/14837#change-72472
* Author: kevinoid (Kevin Locke)
* Status: Closed
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: 2.5.1p57
* Backport: 2.3: REQUIRED, 2.4: REQUIRED, 2.5: REQUIRED
----------------------------------------
Following the [instructions in the Rubygems FAQ](https://guides.rubygems.org/faqs/#user-install) I added the following to `~/.bashrc`:
~~~ sh
if which ruby >/dev/null && which gem >/dev/null; then
PATH="$(ruby -e 'puts Gem.user_dir')/bin:$PATH"
fi
~~~
Unfortunately, this causes login to block for several seconds to minutes (depending on available entropy sources) because `ruby -e 'puts Gem.user_dir'` makes two `getrandom` syscalls without the `GRND_NONBLOCK` flag. On [Linux v4.17-rc2 and later](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=43838a23a05fbd13e47d750d3dfd77001536dd33), this causes ruby, and therefore the login process, to block until the RNG is fully initialized.
Arguably Rubygems could provide/recommend a way to get the user GEM dir without invoking Ruby. That would solve the specific login problem reported above. However, since even `ruby -v` makes two `getrandom` syscalls, I suspect this may cause difficult to diagnose hangs in startup or login scripts for many users and that it is a desirable use case to support, which is why I am reporting it here.
Some relevant history: r51182 added `getrandom`, r51374 added `GRND_NONBLOCK` to address Bug #11395 (similar to this issue), r52808 removed `GRND_NONBLOCK` in some cases for `SecureRandom`.
Thanks for considering,
Kevin
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>