Re: SOCKET_URING_OP_GETSOCKOPT SOL_SOCKET restriction

[Breno Leitao <leitao@debian.org>]

Hello Pavel,

On Fri, Mar 28, 2025 at 05:21:06PM +0000, Pavel Begunkov wrote:
> On 3/28/25 17:18, Pavel Begunkov wrote:
> > On 3/28/25 16:34, Jens Axboe wrote:
> > > On 3/28/25 9:02 AM, Pavel Begunkov wrote:
> > > > On 3/28/25 14:30, Jens Axboe wrote:
> > > > > On 3/28/25 8:27 AM, Stefan Metzmacher wrote:
> > I remember Breno looking at several different options.
> > 
> > Breno, can you remind me, why can't we convert ->getsockopt to
> > take a normal kernel ptr for length while passing a user ptr
> > for value as before?
> 
> Similar to this:
> 
> getsockopt_syscall(void __user *len_uptr) {
> 	int klen;
> 
> 	copy_from_user(&klen, len_uptr);
> 	->getsockopt(&klen);
> 	copy_to_user(len_uptr, &klen);
> }

We have a few limitations if I remember correct:

getsockopt() callback expects __user pointers:

	int             (*getsockopt)(struct socket *sock, int level,
			int optname, char __user *optval, int __user *optlen);


So, you cannot copy the memory content and call ->getsockopt() with
kernel memory.

A solution was to use sockptr, as done by setsockopt(), but, that was
discouraged.

Another important thing, some getsockopt() callback changes the pointer,
so, doing copy_to_user() directly in the getsocktopt callback, which
would break your approach above.

I understand that the next steps here are:

 1) Make getsockopt() operate with either userspace or kernel buffer.
    a) This buffer needs will be written and read on both side. I.e, you
    pass data in the buffer from userspace to kernel space, and kernel
    will overwrite that buffer in kernelspace.

    In other words, this is a read-write buffer (which is not something
    we have in iovec IIRC).

 2) Call the same callbacks from io_uring subsystem using kernel memory

 3) Regular syscalls will continue to user userspace memory.