Re: getsockopt(2)

[christos%astron.com@localhost (Christos Zoulas)]

In article <x7bmjabmv3.fsf%ren.fdy2.co.uk@localhost>,
Robert Swindells  <rjs%fdy2.co.uk@localhost> wrote:
>
>I wrote:
>>Does anyone know why we don't use the input 'optlen' parameter to the
>>getsockopt(2) syscall, we do write back to it on return.
>>
>>In ip_output() there is this, which suggests that someone had come
>>across this before.
>>
>>#if 0   /* defined(IPSEC) */
>>                case IP_IPSEC_POLICY:
>>                {
>>                        struct mbuf *m = NULL;
>>
>>                        /* XXX this will return EINVAL as sopt is empty */
>>                        error = ipsec4_get_policy(inp, sopt->sopt_data,
>>                            sopt->sopt_size, &m);
>>                        if (error == 0)
>>                                error = sockopt_setmbuf(sopt, m);
>>                        break;
>>                }       
>>#endif /*IPSEC*/  
>>
>>There are also lots of places in sctp_usrreq that want to use it.
>>
>>I can set it with the following patch (line numbers will be slightly
>>out), but wondered if there was a reason for the current behaviour.
>>
>>Index: uipc_syscalls.c
>>===================================================================
>>RCS file: /cvsroot/src/sys/kern/uipc_syscalls.c,v
>>retrieving revision 1.187
>>diff -u -r1.187 uipc_syscalls.c
>>--- uipc_syscalls.c	20 Jun 2017 20:34:49 -0000	1.187
>>+++ uipc_syscalls.c	14 Oct 2017 21:33:09 -0000
>>@@ -1235,7 +1240,7 @@
>> 	if ((error = fd_getsock1(SCARG(uap, s), &so, &fp)) != 0)
>> 		return (error);
>> 
>>-	sockopt_init(&sopt, SCARG(uap, level), SCARG(uap, name), 0);
>>+	sockopt_init(&sopt, SCARG(uap, level), SCARG(uap, name), valsize);
>> 
>> 	if (fp->f_flag & FNOSIGPIPE)
>> 		so->so_options |= SO_NOSIGPIPE;
>
>Has anyone had any other thoughts on this ?

Yes, if you don't protect valsize against MCLBYTES like setsockopt does,
it can be used to DoS kernel. Otherwise is can be done. Is 2K enough?

>I'm thinking of adding an extra socket option, maybe SO_PARAM, that you
>would use with setsockopt(2) to set a selector to be used by a following
>getsockopt(2) call.

This would require some state keeping in the kernel and might not be
reliable.

>This wouldn't fix the IPSEC usage without changing userland though.
>
>The alternative is to make both setsockopt(2) and getsockopt(2)
>bidirectional.

So depending on the contents of the sockval we do something different?

>I haven't checked in the userland implementation of sctp_opt_info(3)
>yet. I took the one from FreeBSD but can modify it to work with a
>different API.

Ok.

christos