netdev - HW communication debugging interface

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-next>] [day] [month] [year] [list]

Message-ID: <20150930135141.GF2098@nanopsycho.orion>
Date:	Wed, 30 Sep 2015 15:51:41 +0200
From:	Jiri Pirko <jiri@...nulli.us>
To:	davem@...emloft.net
Cc:	netdev@...r.kernel.org, eladr@...lanox.com, idosch@...lanox.com
Subject: HW communication debugging interface - ideas?

Hi Dave/all.

There is quite common for drivers to speak with HW using "packet-like"
messages. In our case, we put message into skb and push that out as
an ordinary packet. HW then sends us reply in a packet, similar to other
rx-ed packets.

It makes sense to monitor this communication. Not only for debugging
during development, but mainly for collecting data for error reports
from users.

Very cool usecase is to teach wireshark to parse this communication so
one can actually see online what is going on.

Now the question is, what is the correct way to expose this
communication to userspace. Naturally, this interface should be read-only.
Also, the interface should be generic enough so it can be used for all
drivers, including non-net drivers.

1) Special monitoring netdev.
Might make sense to use a separate netdev. Is is easy to tap the
communication. Driver would just create new netdev and push incoming and
outgoing messages there. Downside is that there would be needed to wrap the
messages with some metadata header, which seems quite odd.

2) generic Netlink (genl) interface. Easy to put metadata in, including the
device identificator (pci address). User then can use nlmon in order to
be able to use wireshark to see the netlink messages.

Looks like 2) might be viable, well-defined, generic interface to carry
this info. What do you think? Does this make sense?

Thanks!

Jiri
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html