netdev - Re: [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver

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: <20150225095056.GB4293@localhost.localdomain>
Date:	Wed, 25 Feb 2015 10:50:56 +0100
From:	Richard Cochran <richardcochran@...il.com>
To:	Stathis Voukelatos <stathis.voukelatos@...n.co.uk>
Cc:	linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
	netdev@...r.kernel.org, abrestic@...omium.org
Subject: Re: [PATCH v2 0/3] net: Linn Ethernet Packet Sniffer driver

On Mon, Feb 23, 2015 at 09:37:24AM +0000, Stathis Voukelatos wrote:
> Hi Richard,
> 
> On 18/02/15 21:08, Richard Cochran wrote:
> >On Tue, Feb 17, 2015 at 02:03:30PM +0000, Stathis Voukelatos wrote:
> >>The command string for packet matching is stored in module RAM
> >>and consists of a sequence of 16-bit entries. Each entry includes
> >>an 8-bit command code and and 8-bit data value. Valid command
> >>codes are:
> >>0 - Don't care
> >>1 - Match: packet data must match command string byte
> >>2 - Copy: packet data will be copied to FIFO
> >>3 - Match/Stamp: if packet data matches string byte, a timestamp
> >>                  is copied into the FIFO
> >>4 - Copy/Done: packet data will be copied into the FIFO.
> >>                This command terminates the command string.
> >
> >Why do you need to expose this interface to user space at all?  Why
> >not just time stamp every frame?
> 
> To put this into context with an example, the use case this H/W
> module was originally developed for was to allow multiple audio
> receivers to synchronize with a single transmitter, eg. multi-room
> synchronised audio.

The Linux kernel already fully supports this kind of application via
the SIOCSHWTSTAMP, SO_TIMESTAMPING, and PHC mechanisms.  We certainly
don't need another another interface just for someone's warped
hardware design.

I suggest that you find a way to make your HW work within the existing
frame work.

> The interface needs to be public so that a user-space application
> can program a command string that will match packets that belong to
> the audio stream of interest, for this example.

Let the user program simply use a BPF for that.

> In addition returning just a timestamp would not be enough in many
> cases. In the audio streaming use case mentioned above some
> additional
> bytes from the packet payload need to be returned (with Copy
> commands) in order to associate the timestamp with a certain point
> in the audio stream.

The time stamp is *already* associated with a particular frame.

Just tell your driver to program the hardware to:

1. time stamp every frame
2. deliver every frame

Thats all you need.

> >How does the "Match" command work?  The frame must have one particular
> >byte?  That can't be right.  Please explain.
> 
> Actually, that is how the H/W works. Each Match command is followed by
> a data value which must match the packet data byte at the corresponding
> location. If there is no match processing of the packet stops.

And just what is the "corresponding location"?

Thanks,
Richard
--
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