Re: [PATCH v3 net-next 01/15] net: enetc: add trusted VF support

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch breaks standard Linux SR-IOV semantics by unconditionally preventing untrusted VFs from setting their MAC addresses, and preventing trusted VFs from overriding administratively set MAC addresses.
--

commit d231761f64378426562111f6fe937bf009f559c2
Author: Claudiu Manoil <claudiu.manoil@nxp.com>

net: enetc: add trusted VF support

Some mailbox messages require a higher privilege level to be executed
on behalf of the requesting VF. Introduce a trusted VF flag
(ENETC_VF_FLAG_TRUSTED) and wire up the ndo_set_vf_trust callback via
enetc_pf_set_vf_trust(), which is shared between the enetc and enetc4
PF drivers.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_msg.c b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
> index edc1277bb5860..78114ab3e4820 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_msg.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
[ ... ]
> @@ -61,31 +63,49 @@ static u16 enetc_msg_set_vf_primary_mac_addr(struct enetc_pf *pf, int vf_id,
>  	struct enetc_vf_state *vf_state = &pf->vf_state[vf_id];
>  	struct enetc_msg_mac_exact_filter *msg = vf_msg;
>  	struct device *dev = &pf->si->pdev->dev;
> +	u16 pf_msg = ENETC_PF_MSG_SUCCESS;
>  	char *addr = msg->mac[0].addr;
>  
> +	mutex_lock(&vf_state->lock);
> +
> +	/* Untrusted VFs cannot set their MAC addresses by the mailbox
> +	 * messages.
> +	 */
> +	if (!(vf_state->flags & ENETC_VF_FLAG_TRUSTED)) {
> +		pf_msg = ENETC_PF_MSG_PERM_DENY;
> +		goto vf_state_unlock;
> +	}

[Severity: High]
Does this code break standard Linux SR-IOV semantics?

By unconditionally returning ENETC_PF_MSG_PERM_DENY for untrusted VFs, VMs and
container frameworks that rely on the standard behavior may fail to initialize
networking. Specifically, untrusted VMs that generate and set their own MAC
(when the host has not enforced one) will receive a permission denied response
and fail. Standard drivers typically allow untrusted VFs to set their MAC if
no administrative MAC was assigned by the host.

> +
>  	if (!is_valid_ether_addr(addr)) {
>  		dev_err_ratelimited(dev, "VF%d attempted to set invalid MAC\n",
>  				    vf_id);
> -		return (FIELD_PREP(ENETC_PF_MSG_CLASS_ID,
> -				   ENETC_MSG_CLASS_ID_MAC_FILTER) |
> -			FIELD_PREP(ENETC_PF_MSG_CLASS_CODE,
> -				   ENETC_MF_CLASS_CODE_INVALID_MAC));
> +		pf_msg = FIELD_PREP(ENETC_PF_MSG_CLASS_ID,
> +				    ENETC_MSG_CLASS_ID_MAC_FILTER) |
> +			 FIELD_PREP(ENETC_PF_MSG_CLASS_CODE,
> +				    ENETC_MF_CLASS_CODE_INVALID_MAC);
> +		goto vf_state_unlock;
>  	}
>  
> -	mutex_lock(&vf_state->lock);
> +	/* PF has higher privileges. If PF has already modified the MAC
> +	 * address for VF through .ndo_set_vf_mac() interface, VF is not
> +	 * allowed to set its MAC address via mailbox messages, even if
> +	 * it is trusted.
> +	 */
>  	if (vf_state->flags & ENETC_VF_FLAG_PF_SET_MAC) {
> -		mutex_unlock(&vf_state->lock);
>  		dev_err_ratelimited(dev,
>  				    "VF%d attempted to override PF set MAC\n",
>  				    vf_id);

[Severity: High]
Is this restriction defeating the established kernel purpose of the VF_TRUST
flag?

If a VF is trusted, standard SR-IOV semantics typically allow it to override
administrative restrictions like a host-assigned MAC address. This block
prevents even trusted VFs from overriding a PF-assigned MAC address, causing
a trusted VF to fail with a command not permitted error if it tries to change
a host-assigned MAC.

> -		return FIELD_PREP(ENETC_PF_MSG_CLASS_ID,
> -				  ENETC_MSG_CLASS_ID_CMD_NOT_PERMITTED);
> +		pf_msg = FIELD_PREP(ENETC_PF_MSG_CLASS_ID,
> +				    ENETC_MSG_CLASS_ID_CMD_NOT_PERMITTED);
> +		goto vf_state_unlock;
>  	}
>  
>  	enetc_set_si_hw_addr(pf, vf_id + 1, addr);
> +
> +vf_state_unlock:
>  	mutex_unlock(&vf_state->lock);
>  
> -	return ENETC_PF_MSG_SUCCESS;
> +	return pf_msg;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831025441.635045-1-wei.fang@oss.nxp.com?part=1