public inbox for [email protected]
 help / color / mirror / Atom feed
From: Jens Axboe <[email protected]>
To: Pavel Begunkov <[email protected]>, [email protected]
Cc: [email protected]
Subject: Re: [PATCH 1/1] io_uring: prevent reg-wait speculations
Date: Mon, 18 Nov 2024 18:59:11 -0700	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On 11/18/24 6:43 PM, Pavel Begunkov wrote:
> On 11/19/24 01:29, Jens Axboe wrote:
>> On 11/18/24 6:29 PM, Pavel Begunkov wrote:
>>> With *ENTER_EXT_ARG_REG instead of passing a user pointer with arguments
>>> for the waiting loop the user can specify an offset into a pre-mapped
>>> region of memory, in which case the
>>> [offset, offset + sizeof(io_uring_reg_wait)) will be intepreted as the
>>> argument.
>>>
>>> As we address a kernel array using a user given index, it'd be a subject
>>> to speculation type of exploits.
>>>
>>> Fixes: d617b3147d54c ("io_uring: restore back registered wait arguments")
>>> Fixes: aa00f67adc2c0 ("io_uring: add support for fixed wait regions")
>>> Signed-off-by: Pavel Begunkov <[email protected]>
>>> ---
>>>   io_uring/io_uring.c | 1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
>>> index da8fd460977b..3a3e4fca1545 100644
>>> --- a/io_uring/io_uring.c
>>> +++ b/io_uring/io_uring.c
>>> @@ -3207,6 +3207,7 @@ static struct io_uring_reg_wait *io_get_ext_arg_reg(struct io_ring_ctx *ctx,
>>>                end > ctx->cq_wait_size))
>>>           return ERR_PTR(-EFAULT);
>>>   +    barrier_nospec();
>>>       return ctx->cq_wait_arg + offset;
>>
>> We need something better than that, barrier_nospec() is a big slow
>> hammer...
> 
> Right, more of a discussion opener. I wonder if Jann can help here
> (see the other reply). I don't like back and forth like that, but if
> nothing works there is an option of returning back to reg-wait array
> indexes. Trivial to change, but then we're committing to not expanding
> the structure or complicating things if we do.

Then I think it should've been marked as a discussion point, because we
definitely can't do this. Soliciting input is perfectly fine. And yeah,
was thinking the same thing, if this is an issue then we just go back to
indexing again. At least both the problem and solution is well known
there. The original aa00f67adc2c0 just needed an array_index_nospec()
and it would've been fine.

Not a huge deal in terms of timing, either way.

I suspect we can do something similar here, with just clamping the
indexing offset. But let's hear what Jann thinks.

-- 
Jens Axboe

  reply	other threads:[~2024-11-19  1:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-19  1:29 [PATCH 1/1] io_uring: prevent reg-wait speculations Pavel Begunkov
2024-11-19  1:29 ` Jens Axboe
2024-11-19  1:43   ` Pavel Begunkov
2024-11-19  1:59     ` Jens Axboe [this message]
2024-11-21  0:13       ` Pavel Begunkov
2024-11-19  1:38 ` Pavel Begunkov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox