netdev - Re: [PATCH net-next v2 2/3] bnxt_en: add .get_module_eeprom_by

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YzmvdxQpWviawxuj@shredder>
Date:   Sun, 2 Oct 2022 18:34:15 +0300
From:   Ido Schimmel <idosch@...sch.org>
To:     Michael Chan <michael.chan@...adcom.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, kuba@...nel.org,
        edumazet@...gle.com, pabeni@...hat.com, gospo@...adcom.com,
        vikas.gupta@...adcom.com
Subject: Re: [PATCH net-next v2 2/3] bnxt_en: add
 .get_module_eeprom_by_page() support

On Sat, Oct 01, 2022 at 02:27:10PM -0400, Michael Chan wrote:
> +static int bnxt_get_module_eeprom_by_page(struct net_device *dev,
> +					  const struct ethtool_module_eeprom *page_data,
> +					  struct netlink_ext_ack *extack)
> +{
> +	struct bnxt *bp = netdev_priv(dev);
> +	int rc;
> +
> +	if (bp->link_info.module_status >
> +	    PORT_PHY_QCFG_RESP_MODULE_STATUS_WARNINGMSG) {
> +		NL_SET_ERR_MSG_MOD(extack, "Phy status unknown");

Can you make this more helpful to users? The comment above this check in
bnxt_get_module_info() suggests that it is possible:

/* No point in going further if phy status indicates
 * module is not inserted or if it is powered down or
 * if it is of type 10GBase-T
 */
if (bp->link_info.module_status >
	PORT_PHY_QCFG_RESP_MODULE_STATUS_WARNINGMSG)

> +		return -EIO;
> +	}
> +
> +	if (bp->hwrm_spec_code < 0x10202) {
> +		NL_SET_ERR_MSG_MOD(extack, "Unsupported hwrm spec");

Likewise. As a user I do not know what "hwrm spec" means... Maybe:

NL_SET_ERR_MSG_MOD(extack, "Firmware version too old");

> +		return -EOPNOTSUPP;
> +	}
> +
> +	if (page_data->bank && !(bp->phy_flags & BNXT_PHY_FL_BANK_SEL)) {
> +		NL_SET_ERR_MSG_MOD(extack, "Firmware not capable for bank selection");
> +		return -EOPNOTSUPP;

What happens if you have an old firmware that does not support this
functionality and user space tries to dump page 10h from bank 1 of a
CMIS module that supports multiple banks?

I wanted to say that you would see the wrong information (from bank 0)
because the legacy operations do not support banks and bank 0 is
assumed. However, because only pages 10h-ffh are banked, user space will
get an error from the following check in fallback_set_params():

if (request->page)
	offset = request->page * ETH_MODULE_EEPROM_PAGE_LEN + offset;

[...]

if (offset >= modinfo->eeprom_len)
	return -EINVAL;

I believe it makes sense to be more explicit about it and return an
error in fallback_set_params() in case bank is not 0. Please follow up
if the above analysis is correct.

> +	}
> +
> +	rc = bnxt_read_sfp_module_eeprom_info(bp, page_data->i2c_address << 1,

I was wondering why the shift is needed, but I see that in other places
you are passing 0xA0 and 0xA2 instead of 0x50 and 0x51, so it is OK.

> +					      page_data->page, page_data->bank,
> +					      page_data->offset,
> +					      page_data->length,
> +					      page_data->data);
> +	if (rc) {
> +		NL_SET_ERR_MSG_MOD(extack, "Module`s eeprom read failed");
> +		return rc;
> +	}
> +	return page_data->length;
> +}

Looks good otherwise.

Thanks