Deadlock in when poll is hooked by coroutine lib #355

Activity

1. newpavlov commented on Apr 4, 2023

   

   newpavlov

   on Apr 4, 2023

   Last edited by newpavlov

   Member

   More actions

   Do you mean that libco modifies polling of /dev/random to a yielding operation? If so, I would say it's a clear misuse of getrandom (and, arguably, of Rust code in general). You mix asynchronous operation with synchronous locking primitive. Both must be either synchronous, or asynchronous, not mixed.

   You could "fix" it by using a patched version of getrandom tailored for libco environment, but it's likely you will encounter a heap of similar issues in other Rust crates.
2. asurdo commented on Apr 6, 2023

   

   asurdo

   on Apr 6, 2023

   Last edited by asurdo

   Author

   More actions

   Yes, the yield in libco's poll is what I mean.

   But getrandom is a very general function and will be called in any situation, which means this function should be extremely safe, and the behavior need be predictable. So there should be a not infinity timeout and make a fast fail with a assert.

   In another case, if /dev/random is not readable, dose the poll wait forever?
3. newpavlov commented on Apr 6, 2023

   

   newpavlov

   on Apr 6, 2023

   Last edited by newpavlov

   Member

   More actions

   But getrandom is a very general function and will be called in any situation

   Not in situations where you break fundamental assumptions used in Rust. We can not be and will not be responsible for situations where you intercept syscalls, fundamentally change their behavior, and change threading model under our foot. At the very least you (read, libco) should also intercept the futex syscall, which is used by Rust's std for implementing Mutex and other synchronization primitives on Linux.

   if /dev/random is not readable, dose the poll wait forever?

   Yes, it's possible in low-entropy scenarios (e.g. on virtual machines early in the boot process). Security is one of the highest priorities for us. But we may introduce an option for explicitly opting-in into less blocking, but potentially less secure version of getrandom. But note that your deadlock is unlikely to be caused by this.
4. asurdo commented on Apr 7, 2023

   

   asurdo

   on Apr 7, 2023

   Last edited by asurdo

   Author

   More actions

   Ok, I understand that it's actually the limitations of libco, but I was truly confused when it happened in such a general function.
5. asurdo

   closed this as completedon Apr 7, 2023