Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lord of the Io_uring (2020)

unixism.net

Post reply on HN
Print view View original

1–10 of 20 posts

Re: Lord of the Io_uring (2020)

#3

Post by jeffbee »

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.

Re: Lord of the Io_uring (2020)

#4

Post by coppsilgold »

jeffbee wrote: post #3

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.

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);

Re: Lord of the Io_uring (2020)

#6

Post by LtWorf »

jeffbee wrote: post #3

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.

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

Re: Lord of the Io_uring (2020)

#7

Post by jeffbee »

LtWorf wrote: post #6
jeffbee wrote: post #3

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.

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

Hrmm. "Take over the entire machine" type vulnerabilities, or "these namespaces weren't quite as isolated as we thought" vulnerabilities?

Re: Lord of the Io_uring (2020)

#8

Post by LtWorf »

jeffbee wrote: post #7
LtWorf wrote: post #6

Earlier quoted context omitted.

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

Hrmm. "Take over the entire machine" type vulnerabilities, or "these namespaces weren't quite as isolated as we thought" vulnerabilities?

CVEs are publicly available

Re: Lord of the Io_uring (2020)

#9

Post by epolanski »

jeffbee wrote: post #3

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.

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

Re: Lord of the Io_uring (2020)

#10

Post by chupasaurus »

jeffbee wrote: post #7
LtWorf wrote: post #6

Earlier quoted context omitted.

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

Hrmm. "Take over the entire machine" type vulnerabilities, or "these namespaces weren't quite as isolated as we thought" vulnerabilities?

The latter can easily propagate to the former if seccomp/AppArmor/MAC isn't set properly.
Post reply on HN