net/memif: use abstract socket address

  Abstract socket address has no connection with
filesystem pathnames and the socket dissapears
once all open references are closed.

Memif pmd will use abstract socket address by default.
For backwards compatibility use new argument
'socket-abstract=no'

Signed-off-by: Jakub Grajciar <jgrajcia@cisco.com>
---
 doc/guides/nics/memif.rst         |  1 +
 drivers/net/memif/memif_socket.c  | 25 +++++++++++++++--------
 drivers/net/memif/rte_eth_memif.c | 34 ++++++++++++++++++++++++++++++-
 drivers/net/memif/rte_eth_memif.h | 10 +++++----
 4 files changed, 57 insertions(+), 13 deletions(-)
  

On 10/5/2020 1:39 PM, Jakub Grajciar wrote:
> Abstract socket address has no connection with
> filesystem pathnames and the socket dissapears
> once all open references are closed.
> 
> Memif pmd will use abstract socket address by default.
> For backwards compatibility use new argument
> 'socket-abstract=no'
> 

Why this backward compatibility is required? How the end user affected from 
swithching to abstract sockets?
Since when linux supports abstract sockets, does this switch will cause problem 
with old kernel versions?

Is there any benefit of the abstract sockets other than socket cleaned 
automatically (I assume for unix sockets it is done when file filesystem 
reference removed)?

> Signed-off-by: Jakub Grajciar <jgrajcia@cisco.com>
> ---
>   doc/guides/nics/memif.rst         |  1 +
>   drivers/net/memif/memif_socket.c  | 25 +++++++++++++++--------
>   drivers/net/memif/rte_eth_memif.c | 34 ++++++++++++++++++++++++++++++-
>   drivers/net/memif/rte_eth_memif.h | 10 +++++----
>   4 files changed, 57 insertions(+), 13 deletions(-)
> 
> diff --git a/doc/guides/nics/memif.rst b/doc/guides/nics/memif.rst
> index ddeebed25..8e80105a4 100644
> --- a/doc/guides/nics/memif.rst
> +++ b/doc/guides/nics/memif.rst
> @@ -43,6 +43,7 @@ client.
>      "bsize=1024", "Size of single packet buffer", "2048", "uint16_t"
>      "rsize=11", "Log2 of ring size. If rsize is 10, actual ring size is 1024", "10", "1-14"
>      "socket=/tmp/memif.sock", "Socket filename", "/tmp/memif.sock", "string len 108"
> +   "socket-abstract=no", "Set usage of abstract socket address", "yes", "yes|no"
>      "mac=01:23:45:ab:cd:ef", "Mac address", "01:ab:23:cd:45:ef", ""
>      "secret=abc123", "Secret is an optional security option, which if specified, must be matched by peer", "", "string len 24"
>      "zero-copy=yes", "Enable/disable zero-copy slave mode. Only relevant to slave, requires '--single-file-segments' eal argument", "no", "yes|no"
> diff --git a/drivers/net/memif/memif_socket.c b/drivers/net/memif/memif_socket.c
> index 67794cb6f..4b0b12ead 100644
> --- a/drivers/net/memif/memif_socket.c
> +++ b/drivers/net/memif/memif_socket.c
> @@ -862,10 +862,10 @@ memif_listener_handler(void *arg)
>   }
>   
>   static struct memif_socket *
> -memif_socket_create(char *key, uint8_t listener)
> +memif_socket_create(char *key, uint8_t listener, bool is_abstract)
>   {
>   	struct memif_socket *sock;
> -	struct sockaddr_un un;
> +	struct sockaddr_un un = { 0 };
>   	int sockfd;
>   	int ret;
>   	int on = 1;
> @@ -886,7 +886,12 @@ memif_socket_create(char *key, uint8_t listener)
>   			goto error;
>   
>   		un.sun_family = AF_UNIX;
> -		strlcpy(un.sun_path, sock->filename, MEMIF_SOCKET_UN_SIZE);
> +		if (is_abstract) {
> +			// abstract address

Please don't prefer c99 comment sytle, there are a few occurrences below.
  

> -----Original Message-----
> From: Ferruh Yigit <ferruh.yigit@intel.com>
> Sent: Monday, October 5, 2020 3:09 PM
> To: Jakub Grajciar -X (jgrajcia - PANTHEON TECH SRO at Cisco)
> <jgrajcia@cisco.com>; dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] net/memif: use abstract socket address
> 
> On 10/5/2020 1:39 PM, Jakub Grajciar wrote:
> > Abstract socket address has no connection with filesystem pathnames
> > and the socket dissapears once all open references are closed.
> >
> > Memif pmd will use abstract socket address by default.
> > For backwards compatibility use new argument 'socket-abstract=no'
> >
> 
> Why this backward compatibility is required? How the end user affected from
> swithching to abstract sockets?
> Since when linux supports abstract sockets, does this switch will cause problem
> with old kernel versions?
> 
> Is there any benefit of the abstract sockets other than socket cleaned
> automatically (I assume for unix sockets it is done when file filesystem reference
> removed)?
> 

What I mean by this is compatibility with other implementations and older versions of the driver, e.g. vpp and libmemif don't support abstract socket yet.
  

On Mon, 5 Oct 2020 14:09:20 +0100
Ferruh Yigit <ferruh.yigit@intel.com> wrote:

> On 10/5/2020 1:39 PM, Jakub Grajciar wrote:
> > Abstract socket address has no connection with
> > filesystem pathnames and the socket dissapears
> > once all open references are closed.
> > 
> > Memif pmd will use abstract socket address by default.
> > For backwards compatibility use new argument
> > 'socket-abstract=no'
> >   
> 
> Why this backward compatibility is required? How the end user affected from 
> swithching to abstract sockets?

It would only matter if mixing applications with different versions.

> Since when linux supports abstract sockets, does this switch will cause problem 
> with old kernel versions?

This is not new, it dates back to Linux 2.4 or earlier.

> 
> Is there any benefit of the abstract sockets other than socket cleaned 
> automatically (I assume for unix sockets it is done when file filesystem 
> reference removed)?

The big one is that applications don't have to blindly unlink the old filesystem
remnant. This means that if application can't bind it means another application
is still running with that name. So abstract sockets are safer.


Abstract sockets are not pathnames so they get handled differently by security
systems (like SELinux and AppArmor). This can be helpful in containers.
  

On 10/5/2020 7:17 PM, Stephen Hemminger wrote:
> On Mon, 5 Oct 2020 14:09:20 +0100
> Ferruh Yigit <ferruh.yigit@intel.com> wrote:
> 
>> On 10/5/2020 1:39 PM, Jakub Grajciar wrote:
>>> Abstract socket address has no connection with
>>> filesystem pathnames and the socket dissapears
>>> once all open references are closed.
>>>
>>> Memif pmd will use abstract socket address by default.
>>> For backwards compatibility use new argument
>>> 'socket-abstract=no'
>>>    
>>
>> Why this backward compatibility is required? How the end user affected from
>> swithching to abstract sockets?
> 
> It would only matter if mixing applications with different versions.
> 
>> Since when linux supports abstract sockets, does this switch will cause problem
>> with old kernel versions?
> 
> This is not new, it dates back to Linux 2.4 or earlier.
> 
>>
>> Is there any benefit of the abstract sockets other than socket cleaned
>> automatically (I assume for unix sockets it is done when file filesystem
>> reference removed)?
> 
> The big one is that applications don't have to blindly unlink the old filesystem
> remnant. This means that if application can't bind it means another application
> is still running with that name. So abstract sockets are safer.
> 
> 
> Abstract sockets are not pathnames so they get handled differently by security
> systems (like SELinux and AppArmor). This can be helpful in containers.
> 

Hi Stephen, thank you for clarification.
  

On Mon, 5 Oct 2020 14:39:00 +0200
Jakub Grajciar <jgrajcia@cisco.com> wrote:

> @@ -886,7 +886,12 @@ memif_socket_create(char *key, uint8_t listener)
>  			goto error;
>  
>  		un.sun_family = AF_UNIX;
> -		strlcpy(un.sun_path, sock->filename, MEMIF_SOCKET_UN_SIZE);
> +		if (is_abstract) {
> +			// abstract address
No C++ comments please.

> +			un.sun_path[0] = '\0';
Already set to zero when initialized.

> +	if (pmd->flags & ETH_MEMIF_FLAG_SOCKET_ABSTRACT) {
> +		// abstract address
ditto no C++ comments

> +		sun.sun_path[0] = '\0';
again zeroed again

> +		memcpy(sun.sun_path + 1, pmd->socket_filename, sizeof(sun.sun_path) - 2);
> +	} else
> +		memcpy(sun.sun_path, pmd->socket_filename, sizeof(sun.sun_path) - 1);

This code is buggy since it potentially reads past the end of the strinc in filename.
Use strlcpy here instead.
  

On 10/7/2020 4:03 PM, Stephen Hemminger wrote:
> On Mon, 5 Oct 2020 14:39:00 +0200
> Jakub Grajciar <jgrajcia@cisco.com> wrote:
> 
>> @@ -886,7 +886,12 @@ memif_socket_create(char *key, uint8_t listener)
>>   			goto error;
>>   
>>   		un.sun_family = AF_UNIX;
>> -		strlcpy(un.sun_path, sock->filename, MEMIF_SOCKET_UN_SIZE);
>> +		if (is_abstract) {
>> +			// abstract address
> No C++ comments please.
> 
>> +			un.sun_path[0] = '\0';
> Already set to zero when initialized.
> 
>> +	if (pmd->flags & ETH_MEMIF_FLAG_SOCKET_ABSTRACT) {
>> +		// abstract address
> ditto no C++ comments
> 
>> +		sun.sun_path[0] = '\0';
> again zeroed again
> 
>> +		memcpy(sun.sun_path + 1, pmd->socket_filename, sizeof(sun.sun_path) - 2);
>> +	} else
>> +		memcpy(sun.sun_path, pmd->socket_filename, sizeof(sun.sun_path) - 1);
> 
> This code is buggy since it potentially reads past the end of the strinc in filename.
> Use strlcpy here instead.
> 

Hi Jakub,

v2 is still using memcpy, have you seen Stephen's comment above?