4 ms·

> Seems like less of a rust issue and more of a bug(s) in io_uring? I'm working with io_uring currently and have to disagree hard on that one; io_uring defini

> Seems like less of a rust issue and more of a bug(s) in io_uring? I'm working with io_uring currently and have to disagree hard on that one; io_uring definitely has issues, but the one here is that it's being used incorrectly, not something wrong with io_uring itself. The io_uring issues overall also disaggregate in mostly 2 overall categories: - lack of visibility into io_uring operations since they are no longer syscalls. This is an issue of adding e.g. seccomp and ptrace equivalents into io_uring. It's not something I'd even call a vulnerability, more of a missing feature. - implementation correctness and concurrency issues due to its asynchronicity. It's just hard to do this correctly and bugs are being found and fixed. Some are security vulnerabilities. I'd call this a question of time for it to get stable and ready but I have no reason to believe this won't happen.

mamcx 2y ago
> but the one here is that it's being used incorrectly Being ALLOWED to be used badly, is the major cause of unsafety. And consider that all the reports you reply to are by serious teams. NOT EVEN THEM succeed. That is the #1 definition of > something wrong with io_uring itself
- zbentley 2y ago
  Strongly disagree. At the level of io_uring (syscalls/syscall orchestration), it is expected that available tools are prone to mis-use, and that libraries/higher layers will provide abstractions around them to mitigate that risk. This isn't like the Rust-vs-C argument, where the claim is that you should prefer the option of two equivalently-capable solutions in a space that doesn't allow mis-use. This is more like assembly language, or the fact that memory inside kernel rings is flat and vulnerable: those are low-level tools to facilitate low-level goals with a high risk of mis-use, and the appropriate mitigation for that risk is to build higher-level tools that intercept/prevent that mis-use.
  - eqvinox 2y ago
    Full ACK. To bring it back to the FD leak in the original post: the kernel won't stop you from forgetting to call close() either, io_uring or no.
- cryptonector 2y ago
  > Being ALLOWED to be used badly I don't see how you stop devs from using a system call or similar incorrectly. In this case the result is an FD leak, which is no more than a DoS, and easy to chase and fix [unless the library in question is designed in such a way that the problem is unfixable, in which case abandon that library].

mamcx 2y ago

> but the one here is that it's being used incorrectly Being ALLOWED to be used badly, is the major cause of unsafety. And consider that all the reports you reply to are by serious teams. NOT EVEN THEM succeed. That is the #1 definition of > something wrong with io_uring itself

zbentley 2y ago
Strongly disagree. At the level of io_uring (syscalls/syscall orchestration), it is expected that available tools are prone to mis-use, and that libraries/higher layers will provide abstractions around them to mitigate that risk. This isn't like the Rust-vs-C argument, where the claim is that you should prefer the option of two equivalently-capable solutions in a space that doesn't allow mis-use. This is more like assembly language, or the fact that memory inside kernel rings is flat and vulnerable: those are low-level tools to facilitate low-level goals with a high risk of mis-use, and the appropriate mitigation for that risk is to build higher-level tools that intercept/prevent that mis-use.
- eqvinox 2y ago
  Full ACK. To bring it back to the FD leak in the original post: the kernel won't stop you from forgetting to call close() either, io_uring or no.
cryptonector 2y ago
> Being ALLOWED to be used badly I don't see how you stop devs from using a system call or similar incorrectly. In this case the result is an FD leak, which is no more than a DoS, and easy to chase and fix [unless the library in question is designed in such a way that the problem is unfixable, in which case abandon that library].