Re: SOCKET_URING_OP_GETSOCKOPT SOL_SOCKET restriction

[Pavel Begunkov <asml.silence@gmail.com>]

On 3/28/25 18:22, Breno Leitao wrote:
> 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.

Right, I'm rather asking about changing the callback to pass
a kernel pointer and make the caller to do the copy_to_user
if needed.

> 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.

Do you mean writing to it? That's why the snippet passes a kernel
_pointer_ to length. Did I misunderstand you?

> 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.
> 

-- 
Pavel Begunkov