* Protection key in io uring kthread @ 2023-05-24 2:48 Jeff Xu 2023-05-24 15:06 ` Jens Axboe 0 siblings, 1 reply; 5+ messages in thread From: Jeff Xu @ 2023-05-24 2:48 UTC (permalink / raw) To: io-uring Hi I have a question on the protection key in io_uring. Today, when a user thread enters the kernel through syscall, PKRU is preserved, and the kernel will respect the PKEY protection of memory. For example: sys_mprotect_pkey((void *)ptr, size, PROT_READ | PROT_WRITE, pkey); pkey_write_deny(pkey); <-- disable write access to pkey for this thread. ret = read(fd, ptr, 1); <-- this will fail in the kernel. I wonder what is the case for io_uring, since read is now async, will kthread have the user thread's PKUR ? In theory, it is possible, i.e. from io_uring_enter syscall. But I don't know the implementation details of io_uring, hence asking the expert in this list. Thanks! -Jeff ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Protection key in io uring kthread 2023-05-24 2:48 Protection key in io uring kthread Jeff Xu @ 2023-05-24 15:06 ` Jens Axboe 2023-05-24 17:44 ` Jeff Xu 0 siblings, 1 reply; 5+ messages in thread From: Jens Axboe @ 2023-05-24 15:06 UTC (permalink / raw) To: Jeff Xu, io-uring On 5/23/23 8:48?PM, Jeff Xu wrote: > Hi > I have a question on the protection key in io_uring. Today, when a > user thread enters the kernel through syscall, PKRU is preserved, and > the kernel will respect the PKEY protection of memory. > > For example: > sys_mprotect_pkey((void *)ptr, size, PROT_READ | PROT_WRITE, pkey); > pkey_write_deny(pkey); <-- disable write access to pkey for this thread. > ret = read(fd, ptr, 1); <-- this will fail in the kernel. > > I wonder what is the case for io_uring, since read is now async, will > kthread have the user thread's PKUR ? There is no kthread. What can happen is that some operation may be punted to the io-wq workers, but these act exactly like a thread created by the original task. IOW, if normal threads retain the protection key, so will any io-wq io_uring thread. If they don't, they do not. > In theory, it is possible, i.e. from io_uring_enter syscall. But I > don't know the implementation details of io_uring, hence asking the > expert in this list. Right, if the IO is done inline, then it won't make a difference if eg read(2) is used or IORING_OP_READ (or similar) with io_uring. -- Jens Axboe ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Protection key in io uring kthread 2023-05-24 15:06 ` Jens Axboe @ 2023-05-24 17:44 ` Jeff Xu 2023-05-24 18:04 ` Jens Axboe 0 siblings, 1 reply; 5+ messages in thread From: Jeff Xu @ 2023-05-24 17:44 UTC (permalink / raw) To: Jens Axboe; +Cc: io-uring Hi Jens, Thanks for responding. On Wed, May 24, 2023 at 8:06 AM Jens Axboe <[email protected]> wrote: > > On 5/23/23 8:48?PM, Jeff Xu wrote: > > Hi > > I have a question on the protection key in io_uring. Today, when a > > user thread enters the kernel through syscall, PKRU is preserved, and > > the kernel will respect the PKEY protection of memory. > > > > For example: > > sys_mprotect_pkey((void *)ptr, size, PROT_READ | PROT_WRITE, pkey); > > pkey_write_deny(pkey); <-- disable write access to pkey for this thread. > > ret = read(fd, ptr, 1); <-- this will fail in the kernel. > > > > I wonder what is the case for io_uring, since read is now async, will > > kthread have the user thread's PKUR ? > > There is no kthread. What can happen is that some operation may be > punted to the io-wq workers, but these act exactly like a thread created > by the original task. IOW, if normal threads retain the protection key, > so will any io-wq io_uring thread. If they don't, they do not. > Does this also apply to when the IORING_SETUP_SQPOLL [1] flag is used ? it mentions a kernel thread is created to perform submission queue polling. [1] https://manpages.debian.org/unstable/liburing-dev/io_uring_setup.2.en.html#IORING_SETUP_SQPOLL > > In theory, it is possible, i.e. from io_uring_enter syscall. But I > > don't know the implementation details of io_uring, hence asking the > > expert in this list. > > Right, if the IO is done inline, then it won't make a difference if eg > read(2) is used or IORING_OP_READ (or similar) with io_uring. > Can you please clarify what "IO is done inline" means ? i.e. are there cases that are not inline ? Thanks! -Jeff > -- > Jens Axboe > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Protection key in io uring kthread 2023-05-24 17:44 ` Jeff Xu @ 2023-05-24 18:04 ` Jens Axboe 2023-05-24 19:21 ` Jeff Xu 0 siblings, 1 reply; 5+ messages in thread From: Jens Axboe @ 2023-05-24 18:04 UTC (permalink / raw) To: Jeff Xu; +Cc: io-uring On 5/24/23 11:44?AM, Jeff Xu wrote: > Hi Jens, > Thanks for responding. > > On Wed, May 24, 2023 at 8:06?AM Jens Axboe <[email protected]> wrote: >> >> On 5/23/23 8:48?PM, Jeff Xu wrote: >>> Hi >>> I have a question on the protection key in io_uring. Today, when a >>> user thread enters the kernel through syscall, PKRU is preserved, and >>> the kernel will respect the PKEY protection of memory. >>> >>> For example: >>> sys_mprotect_pkey((void *)ptr, size, PROT_READ | PROT_WRITE, pkey); >>> pkey_write_deny(pkey); <-- disable write access to pkey for this thread. >>> ret = read(fd, ptr, 1); <-- this will fail in the kernel. >>> >>> I wonder what is the case for io_uring, since read is now async, will >>> kthread have the user thread's PKUR ? >> >> There is no kthread. What can happen is that some operation may be >> punted to the io-wq workers, but these act exactly like a thread created >> by the original task. IOW, if normal threads retain the protection key, >> so will any io-wq io_uring thread. If they don't, they do not. >> > Does this also apply to when the IORING_SETUP_SQPOLL [1] flag is used > ? it mentions a kernel thread is created to perform submission queue > polling. It doesn't matter if it's SQPOLL or one of the io-wq workers, they are created in the same way. For all intents and purposes, they are userspace threads, identical to one you'd get with pthread_create(). Only difference is that they never return to userspace. >>> In theory, it is possible, i.e. from io_uring_enter syscall. But I >>> don't know the implementation details of io_uring, hence asking the >>> expert in this list. >> >> Right, if the IO is done inline, then it won't make a difference if eg >> read(2) is used or IORING_OP_READ (or similar) with io_uring. >> > Can you please clarify what "IO is done inline" means ? i.e. are there > cases that are not inline ? I mean if the execution of it ends up being app -> io_uring_enter() -> do io. For some operations, you could end up with: io_uring_enter() -> punt to io_wq io_wq -> do io either implicitly because the "do io" operation doesn't support nonblocking issue (or ran out of resrouces), or explicitly if you set IOSQE_ASYNC in the SQE you submitted. -- Jens Axboe ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Protection key in io uring kthread 2023-05-24 18:04 ` Jens Axboe @ 2023-05-24 19:21 ` Jeff Xu 0 siblings, 0 replies; 5+ messages in thread From: Jeff Xu @ 2023-05-24 19:21 UTC (permalink / raw) To: Jens Axboe; +Cc: io-uring > >>> > >>> I wonder what is the case for io_uring, since read is now async, will > >>> kthread have the user thread's PKUR ? > >> > >> There is no kthread. What can happen is that some operation may be > >> punted to the io-wq workers, but these act exactly like a thread created > >> by the original task. IOW, if normal threads retain the protection key, > >> so will any io-wq io_uring thread. If they don't, they do not. > >> > > Does this also apply to when the IORING_SETUP_SQPOLL [1] flag is used > > ? it mentions a kernel thread is created to perform submission queue > > polling. > > It doesn't matter if it's SQPOLL or one of the io-wq workers, they are > created in the same way. For all intents and purposes, they are > userspace threads, identical to one you'd get with pthread_create(). > Only difference is that they never return to userspace. > Great! Thanks for clarifying. > >>> In theory, it is possible, i.e. from io_uring_enter syscall. But I > >>> don't know the implementation details of io_uring, hence asking the > >>> expert in this list. > >> > >> Right, if the IO is done inline, then it won't make a difference if eg > >> read(2) is used or IORING_OP_READ (or similar) with io_uring. > >> > > Can you please clarify what "IO is done inline" means ? i.e. are there > > cases that are not inline ? > > I mean if the execution of it ends up being app -> io_uring_enter() -> > do io. For some operations, you could end up with: > > io_uring_enter() -> punt to io_wq > io_wq -> do io > > either implicitly because the "do io" operation doesn't support > nonblocking issue (or ran out of resrouces), or explicitly if you set > IOSQE_ASYNC in the SQE you submitted. > Perfect. Thanks! -Jeff Xu ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-05-24 19:22 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-05-24 2:48 Protection key in io uring kthread Jeff Xu 2023-05-24 15:06 ` Jens Axboe 2023-05-24 17:44 ` Jeff Xu 2023-05-24 18:04 ` Jens Axboe 2023-05-24 19:21 ` Jeff Xu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox