Jump to content

Io uring: Difference between revisions

Edit links
From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
O andras (talk | contribs)
127 edits
Adjustments to references
No edit summary
Line 15: Line 15:
The Linux kernel has supported [[asynchronous I/O]] since version 2.5, but it was seen as difficult to use and inefficient.<ref>{{Cite web|last=Corbet|first=Jonathan|title=Ringing in a new asynchronous I/O API|url=https://lwn.net/Articles/776703/|access-date=2021-03-14|website=[[LWN.net]]}}</ref> This older API only supported certain niche [[use cases]],<ref>{{cite web | url = https://kernel.dk/axboe-kr2022.pdf | title = What's new with io_uring | access-date = 2022-06-01}}</ref> notably it only enables asynchronous operation when using the O_DIRECT flag and while accessing already allocated files. This prevents utilizing the [[page cache]], while also exposing the application to complex O_DIRECT semantics. Linux AIO also does not support sockets, so it cannot be used to multiplex network and disk I/O.<ref>{{Cite web |url=http://code.google.com/p/kernel/wiki/AIOUserGuide |title=Linux Asynchronous I/O |date=2014-04-21 |archive-url=https://web.archive.org/web/20150406015143/http://code.google.com/p/kernel/wiki/AIOUserGuide |access-date=2023-06-16 |archive-date=2015-04-06 |quote=Blocking during io_submit on ext4, on buffered operations, network access, pipes, etc. Some operations are not well-represented by the AIO interface. With completely unsupported operations like buffered reads, operations on a socket or pipes, the entire operation will be performed during the io_submit syscall, with the completion available immediately for access with io_getevents. AIO access to a file on a filesystem like ext4 is partially supported: if a metadata read is required to look up the data block (ie if the metadata is not already in memory), then the io_submit call will block on the metadata read. Certain types of file-enlarging writes are completely unsupported and block for the entire duration of the operation. }}</ref>
The Linux kernel has supported [[asynchronous I/O]] since version 2.5, but it was seen as difficult to use and inefficient.<ref>{{Cite web|last=Corbet|first=Jonathan|title=Ringing in a new asynchronous I/O API|url=https://lwn.net/Articles/776703/|access-date=2021-03-14|website=[[LWN.net]]}}</ref> This older API only supported certain niche [[use cases]],<ref>{{cite web | url = https://kernel.dk/axboe-kr2022.pdf | title = What's new with io_uring | access-date = 2022-06-01}}</ref> notably it only enables asynchronous operation when using the O_DIRECT flag and while accessing already allocated files. This prevents utilizing the [[page cache]], while also exposing the application to complex O_DIRECT semantics. Linux AIO also does not support sockets, so it cannot be used to multiplex network and disk I/O.<ref>{{Cite web |url=http://code.google.com/p/kernel/wiki/AIOUserGuide |title=Linux Asynchronous I/O |date=2014-04-21 |archive-url=https://web.archive.org/web/20150406015143/http://code.google.com/p/kernel/wiki/AIOUserGuide |access-date=2023-06-16 |archive-date=2015-04-06 |quote=Blocking during io_submit on ext4, on buffered operations, network access, pipes, etc. Some operations are not well-represented by the AIO interface. With completely unsupported operations like buffered reads, operations on a socket or pipes, the entire operation will be performed during the io_submit syscall, with the completion available immediately for access with io_getevents. AIO access to a file on a filesystem like ext4 is partially supported: if a metadata read is required to look up the data block (ie if the metadata is not already in memory), then the io_submit call will block on the metadata read. Certain types of file-enlarging writes are completely unsupported and block for the entire duration of the operation. }}</ref>


The io_uring kernel interface was adopted in Linux kernel version 5.1 to resolve the deficiencies of Linux AIO.{{R|name=Phoronix2019}}<ref name=":0" /><ref>{{Cite web|title=Faster IO through io_uring |website=Kernel Recipes 2019 |url=https://kernel-recipes.org/en/2019/talks/faster-io-through-io_uring/|access-date=2021-03-14|language=en-GB}}</ref> The {{Code|liburing}} library provides an [[API]] to interact with the kernel interface easily from [[userspace]].{{R|name=Phoronix2019|page=12}}
The io_uring kernel interface was adopted in Linux kernel version 5.1 to resolve the deficiencies of Linux AIO.{{R|name=Phoronix2019}}<ref name=":0" /><ref>{{Cite web|title=Faster IO through io_uring |website=Kernel Recipes 2019 |url=https://kernel-recipes.org/en/2019/talks/faster-io-through-io_uring/|access-date=2021-03-14|language=en-GB}}</ref> The liburing library provides an [[API]] to interact with the kernel interface easily from [[userspace]].{{R|name=Phoronix2019|page=12}}


==Security==
==Security==


<code>io_uring</code> has been noted for exposing a significant attack surface and structural difficulties integrating it with the [[Linux Security Modules|Linux security subsystem]].<ref>{{Cite web |url=https://lwn.net/Articles/902466/ |title=Security requirements for new kernel features |date=2022-07-28 |access-date=2023-06-16 |website=[[LWN.net]] |last=Corbet |first=Jonathan}}</ref>
io_uring has been noted for exposing a significant attack surface and structural difficulties integrating it with the [[Linux Security Modules|Linux security subsystem]].<ref>{{Cite web |url=https://lwn.net/Articles/902466/ |title=Security requirements for new kernel features |date=2022-07-28 |access-date=2023-06-16 |website=[[LWN.net]] |last=Corbet |first=Jonathan}}</ref>


In June 2023, Google's security team reported that 60% of the [[Exploit (computer security)|exploits]] submitted to their [[bug bounty program]] in 2022 were exploits of the Linux kernel's <code>io_uring</code> vulnerabilities. As a result, <code>io_uring</code> was disabled for apps in [[Android (operating system)|Android]], and disabled entirely in [[ChromeOS]] as well as Google servers.<ref>{{cite web |last1=Koczka |first1=Tamás |title=Learnings from kCTF VRP's 42 Linux kernel exploits submissions |url=https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html |website=Google Online Security Blog |publisher=Google |access-date=14 June 2023 |language=en |archive-url=https://web.archive.org/web/20240922183950/https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html |archive-date=2024-09-22 |url-status=live |quote=60% of the submissions exploited the io_uring component of the Linux kernel}}</ref> [[Docker (software)|Docker]] also consequently disabled <code>io_uring</code> from their default [[seccomp]] profile.<ref>{{Cite web |title=Update RuntimeDefault seccomp profile to disallow io_uring related syscalls by vinayakankugoyal · Pull Request #9320 · containerd/containerd |url=https://github.com/containerd/containerd/pull/9320 |date=2023-11-02 |access-date=2024-10-20 |website=GitHub |language=en |archive-url=https://web.archive.org/web/20240106225425/https://github.com/containerd/containerd/pull/9320 |archive-date=2024-01-06 |url-status=live}}</ref>
In June 2023, Google's security team reported that 60% of the [[Exploit (computer security)|exploits]] submitted to their [[bug bounty program]] in 2022 were exploits of the Linux kernel's io_uring vulnerabilities. As a result, <code>io_uring</code> was disabled for apps in [[Android (operating system)|Android]], and disabled entirely in [[ChromeOS]] as well as Google servers.<ref>{{cite web |last1=Koczka |first1=Tamás |title=Learnings from kCTF VRP's 42 Linux kernel exploits submissions |url=https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html |website=Google Online Security Blog |publisher=Google |access-date=14 June 2023 |language=en |archive-url=https://web.archive.org/web/20240922183950/https://security.googleblog.com/2023/06/learnings-from-kctf-vrps-42-linux.html |archive-date=2024-09-22 |url-status=live |quote=60% of the submissions exploited the io_uring component of the Linux kernel}}</ref> [[Docker (software)|Docker]] also consequently disabled io_uring from their default [[seccomp]] profile.<ref>{{Cite web |title=Update RuntimeDefault seccomp profile to disallow io_uring related syscalls by vinayakankugoyal · Pull Request #9320 · containerd/containerd |url=https://github.com/containerd/containerd/pull/9320 |date=2023-11-02 |access-date=2024-10-20 |website=GitHub |language=en |archive-url=https://web.archive.org/web/20240106225425/https://github.com/containerd/containerd/pull/9320 |archive-date=2024-01-06 |url-status=live}}</ref>


== References ==
== References ==

Revision as of 18:31, 15 November 2024

io_uring (previously known as aioring) is a Linux kernel system call interface for storage device asynchronous I/O operations addressing performance issues with similar interfaces provided by functions like read()/write() or aio_read()/aio_write() etc. for operations on data accessed by file descriptors.[1][2]: 2 

Development is ongoing, worked on primarily by Jens Axboe at Meta.[1]

Interface

It works by creating two circular buffers, called "queue rings", for storage of submission and completion of I/O requests, respectively. For storage devices, these are called the submission queue (SQ) and completion queue (CQ).[3] Keeping these buffers shared between the kernel and application helps to boost the I/O performance by eliminating the need to issue extra and expensive system calls to copy these buffers between the two.[1][3][4] According to the io_uring design paper, the SQ buffer is writable only by consumer applications, and the CQ buffer is writable only by the kernel.[1]: 3 

eBPF can be combined with io_uring.[5]

History

The Linux kernel has supported asynchronous I/O since version 2.5, but it was seen as difficult to use and inefficient.[6] This older API only supported certain niche use cases,[7] notably it only enables asynchronous operation when using the O_DIRECT flag and while accessing already allocated files. This prevents utilizing the page cache, while also exposing the application to complex O_DIRECT semantics. Linux AIO also does not support sockets, so it cannot be used to multiplex network and disk I/O.[8]

The io_uring kernel interface was adopted in Linux kernel version 5.1 to resolve the deficiencies of Linux AIO.[1][4][9] The liburing library provides an API to interact with the kernel interface easily from userspace.[1]: 12 

Security

io_uring has been noted for exposing a significant attack surface and structural difficulties integrating it with the Linux security subsystem.[10]

In June 2023, Google's security team reported that 60% of the exploits submitted to their bug bounty program in 2022 were exploits of the Linux kernel's io_uring vulnerabilities. As a result, io_uring was disabled for apps in Android, and disabled entirely in ChromeOS as well as Google servers.[11] Docker also consequently disabled io_uring from their default seccomp profile.[12]

References

  1. ^ a b c d e f "Linux Kernel Getting io_uring To Deliver Fast & Efficient I/O". Phoronix. 2019-02-14. Retrieved 2021-03-14.
  2. ^ Axboe, Jens (October 15, 2019). "Efficient IO with io_uring" (PDF).
  3. ^ a b "Getting Hands-on with io_uring using Go". developers.mattermost.com. Retrieved 2021-11-20.
  4. ^ a b "The rapid growth of io_uring [LWN.net]". lwn.net. Retrieved 2021-11-20.
  5. ^ "BPF meets io_uring [LWN.net]". LWN.net. Retrieved 2023-04-17.
  6. ^ Corbet, Jonathan. "Ringing in a new asynchronous I/O API". LWN.net. Retrieved 2021-03-14.
  7. ^ "What's new with io_uring" (PDF). Retrieved 2022-06-01.
  8. ^ "Linux Asynchronous I/O". 2014-04-21. Archived from the original on 2015-04-06. Retrieved 2023-06-16. Blocking during io_submit on ext4, on buffered operations, network access, pipes, etc. Some operations are not well-represented by the AIO interface. With completely unsupported operations like buffered reads, operations on a socket or pipes, the entire operation will be performed during the io_submit syscall, with the completion available immediately for access with io_getevents. AIO access to a file on a filesystem like ext4 is partially supported: if a metadata read is required to look up the data block (ie if the metadata is not already in memory), then the io_submit call will block on the metadata read. Certain types of file-enlarging writes are completely unsupported and block for the entire duration of the operation.
  9. ^ "Faster IO through io_uring". Kernel Recipes 2019. Retrieved 2021-03-14.
  10. ^ Corbet, Jonathan (2022-07-28). "Security requirements for new kernel features". LWN.net. Retrieved 2023-06-16.
  11. ^ Koczka, Tamás. "Learnings from kCTF VRP's 42 Linux kernel exploits submissions". Google Online Security Blog. Google. Archived from the original on 2024-09-22. Retrieved 14 June 2023. 60% of the submissions exploited the io_uring component of the Linux kernel
  12. ^ "Update RuntimeDefault seccomp profile to disallow io_uring related syscalls by vinayakankugoyal · Pull Request #9320 · containerd/containerd". GitHub. 2023-11-02. Archived from the original on 2024-01-06. Retrieved 2024-10-20.
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Io_uring&oldid=1257589122"