* 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