From: Eugene Syromiatnikov <esyr@redhat.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: linux-fsdevel@vger.kernel.org, io-uring@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-kernel@vger.kernel.org, Jeff Moyer <jmoyer@redhat.com>,
"Dmitry V. Levin" <ldv@altlinux.org>
Subject: Re: [PATCH] io_uring: fix compat for IORING_REGISTER_FILES_UPDATE
Date: Wed, 15 Jan 2020 17:50:17 +0100 [thread overview]
Message-ID: <20200115165017.GI1333@asgard.redhat.com> (raw)
In-Reply-To: <cce5ac48-641d-3051-d22c-dab7aaa5704c@kernel.dk>
On Wed, Jan 15, 2020 at 09:41:58AM -0700, Jens Axboe wrote:
> On 1/15/20 9:35 AM, Eugene Syromiatnikov wrote:
> > fds field of struct io_uring_files_update is problematic with regards
> > to compat user space, as pointer size is different in 32-bit, 32-on-64-bit,
> > and 64-bit user space. In order to avoid custom handling of compat in
> > the syscall implementation, make fds __u64 and use u64_to_user_ptr in
> > order to retrieve it. Also, align the field naturally and check that
> > no garbage is passed there.
>
> Good point, it's an s32 pointer so won't align nicely. But how about
> just having it be:
>
> struct io_uring_files_update {
> __u32 offset;
> __u32 resv;
> __s32 *fds;
> };
>
> which should align nicely on both 32 and 64-bit?
The issue is that 32-bit user space would pass a 12-byte structure with
a 4-byte pointer in it to the 64-bit kernel, that, in turn, would treat it
as a 8-byte value (which might sometimes work on little-endian architectures,
if there are happen to be zeroes after the pointer, but will be always broken
on big-endian ones). __u64 is used in order to avoid special compat wrapper;
see, for example, __u64 usage in btrfs or BPF for similar purposes.
> --
> Jens Axboe
>
next prev parent reply other threads:[~2020-01-15 16:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-15 16:35 [PATCH] io_uring: fix compat for IORING_REGISTER_FILES_UPDATE Eugene Syromiatnikov
2020-01-15 16:41 ` Jens Axboe
2020-01-15 16:50 ` Eugene Syromiatnikov [this message]
2020-01-15 16:53 ` Jens Axboe
2020-01-15 16:59 ` Eugene Syromiatnikov
2020-01-20 23:51 ` Dmitry V. Levin
2020-01-20 23:54 ` Jens Axboe
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 \
--in-reply-to=20200115165017.GI1333@asgard.redhat.com \
--to=esyr@redhat.com \
--cc=axboe@kernel.dk \
--cc=io-uring@vger.kernel.org \
--cc=jmoyer@redhat.com \
--cc=ldv@altlinux.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@zeniv.linux.org.uk \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.