4 ms·

No io_uring explainer is complete without a comprehensive running list of all the vulnerabilities discovered (so far) and the consequent API and behavior change

No io_uring explainer is complete without a comprehensive running list of all the vulnerabilities discovered (so far) and the consequent API and behavior changes. This one, unfortunately, has been static since 2020, which means it comes from the time when io_uring seemed like it might be a fairly OK idea, instead of the toxic waste spill it turned out to be.

LtWorf 1y ago
Also user namespaces have had a long list of vulnerabilities, but that's still better than running docker as root directly.
- jeffbee 1y ago
  Hrmm. "Take over the entire machine" type vulnerabilities, or "these namespaces weren't quite as isolated as we thought" vulnerabilities?
  - LtWorf 1y ago
    CVEs are publicly available
  - cpuguy83 1y ago
    Escalating from an unprivileged user to root by creating userns and exploiting various things in the kernel along the way.
  - chupasaurus 1y ago
    The latter can easily propagate to the former if seccomp/AppArmor/MAC isn't set properly.
- cpuguy83 1y ago
  That is a ridiculous statement. In the case of userns exploits there have been many and it means that every unprivileged user can obtain root on the machine. Whereas rootful docker is a well known thing, run on millions of machines, and none of the vulnerabilities discovered in its entire existence is as bad as any single priv escalation issue caused by allowing unprivileged users to create a user namespace.
  - LtWorf 1y ago
    Lol that's just like saying having no door is better because some people can pick locks and occasionally open doors.
    - cpuguy83 1y ago
      No, it's saying the door is a lie. At least within the context of your statement about vulnerabilities.
coppsilgold 1y ago
While the situation has improved, if your threat model is such you can block io_uring during boot or in containers with a seccomp policy: DENY_RULE (io_uring_enter, EPERM); DENY_RULE (io_uring_register, EPERM); DENY_RULE (io_uring_setup, EPERM);
epolanski 1y ago
All critical flaws seen so far have seen patches and fixes.
Analemma_ 1y ago
What is it with io_uring and btrfs in particular that gives people a compulsive urge to bring up bugs from years ago as proof that they should never be used. Yeah, huge complicated new subsystems land with bugs, and then they gradually get fixed. I’m sorry we can’t all ship perfect bug-free software on the first release, please be kind to us mere mortals.
- jeffbee 1y ago
  io_uring is fundamentally under-designed and will never work correctly. It cannot be incrementally reformed.
  - lantastic 1y ago
    Care to elaborate?
  - yencabulator 1y ago
    You'll need to say a little more than that to be taken seriously. Are you just against all things new, or is there something in the core API that is a bad idea? Surely you're not against the idea of ringbuffers in general, or saying "new thing bad, grug like old thing"? Pretty much everything high performance is ringbuffers these days, e.g. NVMe. What makes io_uring the one thing that cannot be done?

LtWorf 1y ago

Also user namespaces have had a long list of vulnerabilities, but that's still better than running docker as root directly.

jeffbee 1y ago
Hrmm. "Take over the entire machine" type vulnerabilities, or "these namespaces weren't quite as isolated as we thought" vulnerabilities?
- LtWorf 1y ago
  CVEs are publicly available
- cpuguy83 1y ago
  Escalating from an unprivileged user to root by creating userns and exploiting various things in the kernel along the way.
- chupasaurus 1y ago
  The latter can easily propagate to the former if seccomp/AppArmor/MAC isn't set properly.
cpuguy83 1y ago
That is a ridiculous statement. In the case of userns exploits there have been many and it means that every unprivileged user can obtain root on the machine. Whereas rootful docker is a well known thing, run on millions of machines, and none of the vulnerabilities discovered in its entire existence is as bad as any single priv escalation issue caused by allowing unprivileged users to create a user namespace.
- LtWorf 1y ago
  Lol that's just like saying having no door is better because some people can pick locks and occasionally open doors.
  - cpuguy83 1y ago
    No, it's saying the door is a lie. At least within the context of your statement about vulnerabilities.

coppsilgold 1y ago

While the situation has improved, if your threat model is such you can block io_uring during boot or in containers with a seccomp policy: DENY_RULE (io_uring_enter, EPERM); DENY_RULE (io_uring_register, EPERM); DENY_RULE (io_uring_setup, EPERM);

epolanski 1y ago

All critical flaws seen so far have seen patches and fixes.

Analemma_ 1y ago

What is it with io_uring and btrfs in particular that gives people a compulsive urge to bring up bugs from years ago as proof that they should never be used. Yeah, huge complicated new subsystems land with bugs, and then they gradually get fixed. I’m sorry we can’t all ship perfect bug-free software on the first release, please be kind to us mere mortals.

jeffbee 1y ago
io_uring is fundamentally under-designed and will never work correctly. It cannot be incrementally reformed.
- lantastic 1y ago
  Care to elaborate?
- yencabulator 1y ago
  You'll need to say a little more than that to be taken seriously. Are you just against all things new, or is there something in the core API that is a bad idea? Surely you're not against the idea of ringbuffers in general, or saying "new thing bad, grug like old thing"? Pretty much everything high performance is ringbuffers these days, e.g. NVMe. What makes io_uring the one thing that cannot be done?