7 ms·

IIRC the author of io_uring wants to support using it with any system call, not just the current supported subset. Not sure how these efforts are going.

swiley 5y ago
Supporting exec sounds like it could be a security issue. I also have a hard time imagining why on earth you would call exec that way.
- tptacek 5y ago
  Say more about this? You're probably right but I haven't thought about it before and I'd be happy to have you do that thinking for me. :)
  - touisteur 5y ago
    Start a user-provided compression background task at file close? Think tcpdump with io_uring 'take this here buffer you've just read and send it to disk without bothering userland.
- the_duke 5y ago
  > Supporting exec sounds like it could be a security issue. Why would it be any more of an issue than calling a blocking exec? > why on earth you would call exec that way The same reason as why you would want to do anything else with io_uring? In an async runtime you have to delegate blocking calls to a thread pool. Much nicer if the runtime can use the same execution system as for other IO.
  - swiley 5y ago
    >Why would it be any more of an issue than calling a blocking exec? Now you turn everything doing fast I/O into something that's essentially an easier rwx situation WRT memory corruption. >Much nicer In other words: the runtime should handle it because the kernel doesn't need to.
    - the_duke 5y ago
      I really don't follow your thought process here. Can you expand on your objections? io_uring can really be thought of as a generic asynchronous syscall interface. It uses a kernel thread pool to run operations. If something is blocking on a kernel-level it can just be run as a blocking operation on that thread pool.
      - wtallis 5y ago
        I think the concern is that if you can manage an exploit that injects data into an io_uring submission queue, you may be able to plant an exec call or similar. But such an exploit would need to rely on a well-formed malicious SQE being submitted to the kernel without being overwritten by the SQE the application intended to submit, which probably requires also gaining control over the application's pointers for where in the queue it will write the next SQE it constructs.
    - Aissen 5y ago
      Meh, I'm a bit skeptic. Memory corruption of ring buffer could make it possible to inject exec syscalls. So, like any other memory corruption ? Also, io_uring already supports open/read/write which is often enough to convert to execution.
  - hinkley 5y ago
    If you can emulate blocking calls in user space for backward compatibility, that is probably best. But I wonder about process scheduling. Blocked threads don't get rescheduled until the kernel unblocks them. Can you tell the kernel to block a thread until an io_uring state change occurs?
    - wtallis 5y ago
      > Can you tell the kernel to block a thread until an io_uring state change occurs? The same syscall used to inform the kernel that you're submitting N new operations can also specify that it should block waiting for M completions. One of those completions could be for a timeout command that was previously submitted.

swiley 5y ago

Supporting exec sounds like it could be a security issue. I also have a hard time imagining why on earth you would call exec that way.

tptacek 5y ago
Say more about this? You're probably right but I haven't thought about it before and I'd be happy to have you do that thinking for me. :)
- touisteur 5y ago
  Start a user-provided compression background task at file close? Think tcpdump with io_uring 'take this here buffer you've just read and send it to disk without bothering userland.
the_duke 5y ago
> Supporting exec sounds like it could be a security issue. Why would it be any more of an issue than calling a blocking exec? > why on earth you would call exec that way The same reason as why you would want to do anything else with io_uring? In an async runtime you have to delegate blocking calls to a thread pool. Much nicer if the runtime can use the same execution system as for other IO.
- swiley 5y ago
  >Why would it be any more of an issue than calling a blocking exec? Now you turn everything doing fast I/O into something that's essentially an easier rwx situation WRT memory corruption. >Much nicer In other words: the runtime should handle it because the kernel doesn't need to.
  - the_duke 5y ago
    I really don't follow your thought process here. Can you expand on your objections? io_uring can really be thought of as a generic asynchronous syscall interface. It uses a kernel thread pool to run operations. If something is blocking on a kernel-level it can just be run as a blocking operation on that thread pool.
    - wtallis 5y ago
      I think the concern is that if you can manage an exploit that injects data into an io_uring submission queue, you may be able to plant an exec call or similar. But such an exploit would need to rely on a well-formed malicious SQE being submitted to the kernel without being overwritten by the SQE the application intended to submit, which probably requires also gaining control over the application's pointers for where in the queue it will write the next SQE it constructs.
  - Aissen 5y ago
    Meh, I'm a bit skeptic. Memory corruption of ring buffer could make it possible to inject exec syscalls. So, like any other memory corruption ? Also, io_uring already supports open/read/write which is often enough to convert to execution.
- hinkley 5y ago
  If you can emulate blocking calls in user space for backward compatibility, that is probably best. But I wonder about process scheduling. Blocked threads don't get rescheduled until the kernel unblocks them. Can you tell the kernel to block a thread until an io_uring state change occurs?
  - wtallis 5y ago
    > Can you tell the kernel to block a thread until an io_uring state change occurs? The same syscall used to inform the kernel that you're submitting N new operations can also specify that it should block waiting for M completions. One of those completions could be for a timeout command that was previously submitted.