public inbox for [email protected]
 help / color / mirror / Atom feed
From: Pavel Begunkov <[email protected]>
To: Ming Lei <[email protected]>
Cc: Jens Axboe <[email protected]>,
	[email protected], [email protected],
	Uday Shankar <[email protected]>,
	Akilesh Kailash <[email protected]>
Subject: Re: [PATCH V8 5/7] io_uring: support leased group buffer with REQ_F_GROUP_KBUF
Date: Mon, 4 Nov 2024 13:24:09 +0000	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <ZyjHQN9VITpOlyPA@fedora>

On 11/4/24 13:08, Ming Lei wrote:
> On Mon, Nov 04, 2024 at 12:23:04PM +0000, Pavel Begunkov wrote:
>> On 11/4/24 01:21, Ming Lei wrote:
...>>>> 3. The lease ends, and we copy full 4K back to user space with the
>>>> unitialised chunk.
>>>>
>>>> You can correct me on ublk specifics, I assume 3. is not a copy and
>>>> the user in 3 is the one using a ublk block device, but the point I'm
>>>> making is that if something similar is possible, then just zeroing is not
>>>> enough, the user can skip the step filling the buffer. If it can't leak
>>>
>>> Can you explain how user skips the step given read IO is member of one group?
>>
>> (2) Illustrates it, it can also be a nop with no read/recv
> 
> As I explained before, the application has to be trusted, and it must
> have the permission to open the device & call into the buffer lease
> uring_cmd.

It might be trusted to read some data of the process using the
device, but obviously it can't be trusted to read random kernel data.
I'm trying to understand which one is that.

> It is in same situation with any user emulated storage, such as qemu,
> fuse, and the application has to do things right.
> 
>>
>>>> any private data, then the buffer should've already been initialised by
>>>> the time it was lease. Initialised is in the sense that it contains no
>>>
>>> For block IO the practice is to zero the remainder after short read, please
>>> see example of loop, lo_complete_rq() & lo_read_simple().
>>
>> It's more important for me to understand what it tries to fix, whether
>> we can leak kernel data without the patch, and whether it can be exploited
>> even with the change. We can then decide if it's nicer to zero or not.
>>
>> I can also ask it in a different way, can you tell is there some security
>> concern if there is no zeroing? And if so, can you describe what's the exact
>> way it can be triggered?
> 
> Firstly the zeroing follows loop's handling for short read

> Secondly, if the remainder part of one page cache buffer isn't zeroed, it might
> be leaked to userspace via another read() or mmap() on same page.

What kind of data this leaked buffer can contain? Is it uninitialised
kernel memory like a freshly kmalloc'ed chunk would have? Or is it private
data of some user process?

-- 
Pavel Begunkov

  reply	other threads:[~2024-11-04 13:24 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-25 12:22 [PATCH V8 0/8] io_uring: support sqe group and leased group kbuf Ming Lei
2024-10-25 12:22 ` [PATCH V8 1/7] io_uring: add io_link_req() helper Ming Lei
2024-10-25 12:22 ` [PATCH V8 2/7] io_uring: add io_submit_fail_link() helper Ming Lei
2024-10-25 12:22 ` [PATCH V8 3/7] io_uring: add helper of io_req_commit_cqe() Ming Lei
2024-10-25 12:22 ` [PATCH V8 4/7] io_uring: support SQE group Ming Lei
2024-10-29  0:12   ` Jens Axboe
2024-10-29  1:50     ` Ming Lei
2024-10-29 16:38       ` Pavel Begunkov
2024-10-31 21:24   ` Jens Axboe
2024-10-31 21:39     ` Jens Axboe
2024-11-01  0:00       ` Jens Axboe
2024-10-25 12:22 ` [PATCH V8 5/7] io_uring: support leased group buffer with REQ_F_GROUP_KBUF Ming Lei
2024-10-29 16:47   ` Pavel Begunkov
2024-10-30  0:45     ` Ming Lei
2024-10-30  1:25       ` Pavel Begunkov
2024-10-30  2:04         ` Ming Lei
2024-10-31 13:16           ` Pavel Begunkov
2024-11-01  1:04             ` Ming Lei
2024-11-03 22:31               ` Pavel Begunkov
2024-11-04  0:16                 ` Ming Lei
2024-11-04  1:08                   ` Pavel Begunkov
2024-11-04  1:21                     ` Ming Lei
2024-11-04 12:23                       ` Pavel Begunkov
2024-11-04 13:08                         ` Ming Lei
2024-11-04 13:24                           ` Pavel Begunkov [this message]
2024-11-04 13:35                             ` Ming Lei
2024-11-04 16:38                               ` Pavel Begunkov
2024-11-05  3:37                                 ` Ming Lei
2024-10-25 12:22 ` [PATCH V8 6/7] io_uring/uring_cmd: support leasing device kernel buffer to io_uring Ming Lei
2024-10-25 12:22 ` [PATCH V8 7/7] ublk: support leasing io " Ming Lei
2024-10-29 17:01 ` [PATCH V8 0/8] io_uring: support sqe group and leased group kbuf Pavel Begunkov
2024-10-29 17:04   ` Jens Axboe
2024-10-29 19:18     ` Jens Axboe
2024-10-29 20:06       ` Jens Axboe
2024-10-29 21:26         ` Jens Axboe
2024-10-30  2:03           ` Ming Lei
2024-10-30  2:43             ` Jens Axboe
2024-10-30  3:08               ` Ming Lei
2024-10-30  4:11                 ` Ming Lei
2024-10-30 13:20                   ` Jens Axboe
2024-10-31  2:53                     ` Ming Lei
2024-10-31 13:35                       ` Jens Axboe
2024-10-31 15:07                         ` Jens Axboe
2024-11-01  2:57                           ` Ming Lei
2024-11-01  1:39                         ` Ming Lei
2024-10-31 13:42                       ` Pavel Begunkov
2024-10-30 13:18                 ` Jens Axboe
2024-10-31 13:25               ` Pavel Begunkov
2024-10-31 14:29                 ` Jens Axboe
2024-10-31 15:25                   ` Pavel Begunkov
2024-10-31 15:42                     ` Jens Axboe
2024-10-31 16:29                       ` 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] \
    [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