[net-next,v5,01/22] rtnetlink: provide permanent hardware address in RTM_NEWLINK

Permanent hardware address of a network device was traditionally provided
via ethtool ioctl interface but as Jiri Pirko pointed out in a review of
ethtool netlink interface, rtnetlink is much more suitable for it so let's
add it to the RTM_NEWLINK message.

As permanent address is not modifiable, reject userspace requests
containing IFLA_PERM_ADDRESS attribute.

Note: we already provide permanent hardware address for bond slaves;
unfortunately we cannot drop that attribute for backward compatibility
reasons.

Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
---
 include/uapi/linux/if_link.h | 1 +
 net/core/rtnetlink.c         | 4 ++++
 2 files changed, 5 insertions(+)

Mon, Mar 25, 2019 at 06:07:57PM CET, mkubecek@suse.cz wrote:
>Permanent hardware address of a network device was traditionally provided
>via ethtool ioctl interface but as Jiri Pirko pointed out in a review of
>ethtool netlink interface, rtnetlink is much more suitable for it so let's
>add it to the RTM_NEWLINK message.
>
>As permanent address is not modifiable, reject userspace requests
>containing IFLA_PERM_ADDRESS attribute.
>
>Note: we already provide permanent hardware address for bond slaves;
>unfortunately we cannot drop that attribute for backward compatibility
>reasons.
>
>Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
>---
> include/uapi/linux/if_link.h | 1 +
> net/core/rtnetlink.c         | 4 ++++
> 2 files changed, 5 insertions(+)
>
>diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h
>index 5b225ff63b48..351ef746b8b0 100644
>--- a/include/uapi/linux/if_link.h
>+++ b/include/uapi/linux/if_link.h
>@@ -167,6 +167,7 @@ enum {
> 	IFLA_NEW_IFINDEX,
> 	IFLA_MIN_MTU,
> 	IFLA_MAX_MTU,
>+	IFLA_PERM_ADDRESS,
> 	__IFLA_MAX
> };
> 
>diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>index a51cab95ba64..a72e8f4d777b 100644
>--- a/net/core/rtnetlink.c
>+++ b/net/core/rtnetlink.c
>@@ -1026,6 +1026,7 @@ static noinline size_t if_nlmsg_size(const struct net_device *dev,
> 	       + nla_total_size(4)  /* IFLA_CARRIER_DOWN_COUNT */
> 	       + nla_total_size(4)  /* IFLA_MIN_MTU */
> 	       + nla_total_size(4)  /* IFLA_MAX_MTU */
>+	       + nla_total_size(MAX_ADDR_LEN) /* IFLA_PERM_ADDRESS */
> 	       + 0;
> }
> 
>@@ -1683,6 +1684,8 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb,
> 	    nla_put_s32(skb, IFLA_NEW_IFINDEX, new_ifindex) < 0)
> 		goto nla_put_failure;
> 
>+	if (nla_put(skb, IFLA_PERM_ADDRESS, dev->addr_len, dev->perm_addr))
>+		goto nla_put_failure;

I don't think we should put permaddr if driver did not set it. 2
solutions:
1) provide a helper that driver will use to set the perm_addr. This
   helper sets a "valid bit". Then you only put IFLA_PERM_ADDRESS
   in case the "valid bit" is set.
2) Assuming that no driver would set permaddr to all zeroes,
   don't put IFLA_PERM_ADDRESS in case permadd is all zeroes.

> 
> 	rcu_read_lock();
> 	if (rtnl_fill_link_af(skb, dev, ext_filter_mask))
>@@ -1742,6 +1745,7 @@ static const struct nla_policy ifla_policy[IFLA_MAX+1] = {
> 	[IFLA_CARRIER_DOWN_COUNT] = { .type = NLA_U32 },
> 	[IFLA_MIN_MTU]		= { .type = NLA_U32 },
> 	[IFLA_MAX_MTU]		= { .type = NLA_U32 },
>+	[IFLA_PERM_ADDRESS]	= { .type = NLA_REJECT },
> };
> 
> static const struct nla_policy ifla_info_policy[IFLA_INFO_MAX+1] = {
>-- 
>2.21.0
>

On Tue, Mar 26, 2019 at 11:08:36AM +0100, Jiri Pirko wrote:
> 
> I don't think we should put permaddr if driver did not set it. 2
> solutions:
> 1) provide a helper that driver will use to set the perm_addr. This
>    helper sets a "valid bit". Then you only put IFLA_PERM_ADDRESS
>    in case the "valid bit" is set.
> 2) Assuming that no driver would set permaddr to all zeroes,
>    don't put IFLA_PERM_ADDRESS in case permadd is all zeroes.

I already replied to similar suggestion in v4 discussion:

  http://patchwork.ozlabs.org/patch/1060164/#2117512

But I don't have really strong opinion about this. The problem with not
being able to distinguish between "no/unknown permanent address" and
"old kernel not providing the information" is going to become less
important over time.

Michal

Tue, Mar 26, 2019 at 11:31:15AM CET, mkubecek@suse.cz wrote:
>On Tue, Mar 26, 2019 at 11:08:36AM +0100, Jiri Pirko wrote:
>> 
>> I don't think we should put permaddr if driver did not set it. 2
>> solutions:
>> 1) provide a helper that driver will use to set the perm_addr. This
>>    helper sets a "valid bit". Then you only put IFLA_PERM_ADDRESS
>>    in case the "valid bit" is set.
>> 2) Assuming that no driver would set permaddr to all zeroes,
>>    don't put IFLA_PERM_ADDRESS in case permadd is all zeroes.
>
>I already replied to similar suggestion in v4 discussion:
>
>  http://patchwork.ozlabs.org/patch/1060164/#2117512
>
>But I don't have really strong opinion about this. The problem with not
>being able to distinguish between "no/unknown permanent address" and
>"old kernel not providing the information" is going to become less
>important over time.

If the attribute is sent to userspace, it should mean the permaddr is
there and valid.


>
>Michal

From: Michal Kubecek <mkubecek@suse.cz>
Date: Mon, 25 Mar 2019 18:07:57 +0100 (CET)

> @@ -1683,6 +1684,8 @@ static int rtnl_fill_ifinfo(struct sk_buff *skb,
>  	    nla_put_s32(skb, IFLA_NEW_IFINDEX, new_ifindex) < 0)
>  		goto nla_put_failure;
>  
> +	if (nla_put(skb, IFLA_PERM_ADDRESS, dev->addr_len, dev->perm_addr))
> +		goto nla_put_failure;
>  
>  	rcu_read_lock();
>  	if (rtnl_fill_link_af(skb, dev, ext_filter_mask))

I guess, as Jiri says, we really do have to check if the driver
actually set this before pushing the attribute out to userspace.

But seriously, you chould just check for dev_addr_len zeros.

All zeros is not a valid link address on any link type.