4 ms·

io_uring is wonderful.

by lukeh 3y ago

topspin 3y ago
io_uring has produced many security problems. Google has found it necessary to either completely forego io_uring or severely limit its use to trusted code[1]. This policy includes Chrome OS, Android and Google Cloud. Docker has also blocked io_uring syscalls (by default) from being called by containers for the same reason and, although they've flip flopped on this at least once, I believe io_uring is currently blocked. This is highly disappointing to me, but also not surprising given the nature of io_uring. Solving it will require more design rigor, probably some performance compromises and possibly some degree of formal validation. [1] https://www.phoronix.com/news/Google-Restricting-IO_uring https://www.phoronix.com/news/Google-Restricting-IO_uring
- hinkley 3y ago
  “Faster than possible” is a phrase I picked up an awfully long time ago. I hope someone finds a reasonable middle ground that’s still several times faster but not Swiss cheese.
- adrian_b 3y ago
  The security problems for io_uring or for any other system calls exist only when an adversary has access to those system calls. Whenever you write an application for internal use, where there is no possibility for an adversary to interfere and control in any way the arguments of the system calls, there is no reason to avoid io_uring or other risky system calls.
  - littlestymaar 3y ago
    Defense in depth through sanboxing is there to make sure that even an attacker that get some amount of undue privilege will not be able to do harm. At this point we've learned that all existing systems will have vulnerabilities of some sort, so defense in depth is the only credible security posture.
- FridgeSeal 3y ago
  You’ve written the same message, almost verbatim multiple times in this thread. Google also writes applications in golang, maintains their own version of the Linux kernel and runs a browser monopoly. What works/doesn’t work for them shouldn’t be treated as the only standard worth considering. FWIW, fb makes plentiful use of it as I understand. Docker doesn’t block IO_URING syscalls, you just have to be able to lock memory. Clearly you have an axe to grind about io_uring, which is fine, I guess? But you’re really going out of your way to make it seem like it’s the worst thing ever, which is a extra.
  - topspin 3y ago
    > You’ve written the same message, almost verbatim multiple times in this thread. Until now I had written exactly one message in this thread. If others have made similar statements or cited the same link it's down to the fact that some of us care a great deal and are enthusiastic about io_uring, so this relatively recent information is top of mind. > Docker doesn’t block IO_URING syscalls "Update RuntimeDefault seccomp profile to disallow io_uring related syscalls" from containerd-2.0.0 beta2 release[1], 3 weeks ago... (bear in mind there is considerable history here.) What a bizarre reply. [1] https://github.com/containerd/containerd/releases/tag/v2.0.0-beta.2 https://github.com/containerd/containerd/releases/tag/v2.0.0...
  - surajrmal 3y ago
    Does Facebook have the same threat model? They don't run a public cloud nor host enterprise data.
  - mikestew 3y ago
    You’ve written the same message, almost verbatim multiple times in this thread Comment history says otherwise. If you’re going to make ad hominems, at least make ‘em accurate.
- secondcoming 3y ago
  I just checked one of our GCP VMs, and it seems it's supported there: # grep -i uring /boot/config-$(uname -r) CONFIG_IO_URING=y
  - topspin 3y ago
    (message #3 attributable to me, since someone appears to be counting...) "Google production servers" is what I should have written. io_uring on your GPC VMs has no security implications for Google itself.

io_uring is wonderful.

by lukeh 3y ago

io_uring is wonderful.

io_uring has produced many security problems. Google has found it necessary to either completely forego io_uring or severely limit its use to trusted code[1]. This policy includes Chrome OS, Android and Google Cloud. Docker has also blocked io_uring syscalls (by default) from being called by containers for the same reason and, although they've flip flopped on this at least once, I believe io_uring is currently blocked. This is highly disappointing to me, but also not surprising given the nature of io_uring. Solving it will require more design rigor, probably some performance compromises and possibly some degree of formal validation. [1] https://www.phoronix.com/news/Google-Restricting-IO_uring https://www.phoronix.com/news/Google-Restricting-IO_uring

hinkley 3y ago
“Faster than possible” is a phrase I picked up an awfully long time ago. I hope someone finds a reasonable middle ground that’s still several times faster but not Swiss cheese.
adrian_b 3y ago
The security problems for io_uring or for any other system calls exist only when an adversary has access to those system calls. Whenever you write an application for internal use, where there is no possibility for an adversary to interfere and control in any way the arguments of the system calls, there is no reason to avoid io_uring or other risky system calls.
- littlestymaar 3y ago
  Defense in depth through sanboxing is there to make sure that even an attacker that get some amount of undue privilege will not be able to do harm. At this point we've learned that all existing systems will have vulnerabilities of some sort, so defense in depth is the only credible security posture.
FridgeSeal 3y ago
You’ve written the same message, almost verbatim multiple times in this thread. Google also writes applications in golang, maintains their own version of the Linux kernel and runs a browser monopoly. What works/doesn’t work for them shouldn’t be treated as the only standard worth considering. FWIW, fb makes plentiful use of it as I understand. Docker doesn’t block IO_URING syscalls, you just have to be able to lock memory. Clearly you have an axe to grind about io_uring, which is fine, I guess? But you’re really going out of your way to make it seem like it’s the worst thing ever, which is a extra.
- topspin 3y ago
  > You’ve written the same message, almost verbatim multiple times in this thread. Until now I had written exactly one message in this thread. If others have made similar statements or cited the same link it's down to the fact that some of us care a great deal and are enthusiastic about io_uring, so this relatively recent information is top of mind. > Docker doesn’t block IO_URING syscalls "Update RuntimeDefault seccomp profile to disallow io_uring related syscalls" from containerd-2.0.0 beta2 release[1], 3 weeks ago... (bear in mind there is considerable history here.) What a bizarre reply. [1] https://github.com/containerd/containerd/releases/tag/v2.0.0-beta.2 https://github.com/containerd/containerd/releases/tag/v2.0.0...
- surajrmal 3y ago
  Does Facebook have the same threat model? They don't run a public cloud nor host enterprise data.
- mikestew 3y ago
  You’ve written the same message, almost verbatim multiple times in this thread Comment history says otherwise. If you’re going to make ad hominems, at least make ‘em accurate.
secondcoming 3y ago
I just checked one of our GCP VMs, and it seems it's supported there: # grep -i uring /boot/config-$(uname -r) CONFIG_IO_URING=y
- topspin 3y ago
  (message #3 attributable to me, since someone appears to be counting...) "Google production servers" is what I should have written. io_uring on your GPC VMs has no security implications for Google itself.