Re: getsockopt(2)

[Robert Swindells <rjs%fdy2.co.uk@localhost>]

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 ?

I still think that the one line change shown here is correct, it will 
allocate a buffer that gets filled by the stuff to be copied back to
userspace.

The SCTP API that is defined in RFC 6458 does allow for the case where
getsockopt(2) and setsockopt(2) are both unidirectional. The API defines
a wrapper function sctp_opt_info(3) that can hide whatever mechanism
is used to pass into the kernel an extra parameter to be used to select
what is returned by getsockopt(2).

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 wouldn't fix the IPSEC usage without changing userland though.

The alternative is to make both setsockopt(2) and getsockopt(2)
bidirectional.

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.