netdev - Re: [PATCH net-next 0/6] mlxsw: Add extended ACK for EMADs

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]

Date:   Mon, 4 Nov 2019 12:39:54 -0800
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Ido Schimmel <idosch@...sch.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net, jiri@...lanox.com,
        shalomt@...lanox.com, mlxsw@...lanox.com,
        Ido Schimmel <idosch@...lanox.com>
Subject: Re: [PATCH net-next 0/6] mlxsw: Add extended ACK for EMADs

On Sun,  3 Nov 2019 10:35:48 +0200, Ido Schimmel wrote:
> From: Ido Schimmel <idosch@...lanox.com>
> 
> Ethernet Management Datagrams (EMADs) are Ethernet packets sent between
> the driver and device's firmware. They are used to pass various
> configurations to the device, but also to get events (e.g., port up)
> from it. After the Ethernet header, these packets are built in a TLV
> format.
> 
> Up until now, whenever the driver issued an erroneous register access it
> only got an error code indicating a bad parameter was used. This patch
> set from Shalom adds a new TLV (string TLV) that can be used by the
> firmware to encode a 128 character string describing the error. The new
> TLV is allocated by the driver and set to zeros. In case of error, the
> driver will check the length of the string in the response and print it
> to the kernel log.
> 
> Example output:
> 
> mlxsw_spectrum 0000:03:00.0: EMAD reg access failed (tid=a9719f9700001306,reg_id=8018(rauhtd),type=query,status=7(bad parameter))
> mlxsw_spectrum 0000:03:00.0: Firmware error (tid=a9719f9700001306,emad_err_string=inside er_rauhtd_write_query(), num_rec=32 is over the maximum number of records supported)

Personally I'm not a big fan of passing unstructured data between user
and firmware. Not having access to the errors makes it harder to create
common interfaces by inspecting driver code.

Is there any precedent in the tree for printing FW errors into the logs
like this?