netdev - Re: IPv6 over firewire

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:	Sat, 12 Jan 2013 15:37:55 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	stephan.gatzka@...il.com
Cc:	linux1394-devel@...ts.sourceforge.net, yoshfuji@...ux-ipv6.org,
	netdev@...r.kernel.org
Subject: Re: IPv6 over firewire

On Jan 12 Stephan Gatzka wrote:
> > Or the (optional!) callback could be a new member of struct ndisc_options.
> 
> Hm, right now I have no opinion on that. Where does
> whatever_type *callback comes from? Is it an exported method of the 
> firewire net driver or the new function pointer in struct netdevice?

The networking core or IPv6 core would never ever use an EXPORT() from an
interface driver like firewire-net or from a bus architecture driver like
firewire-core.

The interface driver uses definitions and declarations from the networking/
IP/ ARP... core:
  - functions implemented in the core and EXPORTed from there,
  - data types defined in core headers and filled with data by the
    interface driver,
  - callback function types defined in core headers, used in data types
    which are defined in core headers; respective callbacks implemented in
    interface drivers, pointers to the implementations filled in by the
    interface drivers into respective data objects.
So the firewire-net bridge driver uses the firewire-core API below it and
the networking and IP APIs above it.

Whether a callback is needed at all is not obvious to me.  If one is
needed, then it is not obvious to me whether it should be reachable via a
function pointer in struct net_device, or via a function pointer in one of
the pointer table structs that are appended to struct net_device, or via a
function pointer in e.g. struct ndisc_options, or via a function pointer
typed argument of a function which is EXPORTed by the networking/ IPv6
core.

> > However, does net/ipv6/ndisc.c really need to be aware of the RFC 3146
> > Neighbor Discovery related packet header layouts?  Isn't it possible to
> > rewrite these headers in-place in drivers/firewire/net.c?
> 
> 
> Yes, it it possible, but yoshfuji strongly voted against rewriting ndisc 
> packets in firewire net driver to maintain extensibility to protocols. 
> Especially IPSEC can just not work if I rewrite the packets in the driver.

OK, then net/ipv6/ndisc.c shall be taught to write (and read?) those
packets, and drivers/firewire/net.c shall fill in all data that are going
to be needed by ndisc.c into new arguments of existing or new exported
core functions, or into new members of whichever networking struct
would be most suitable for that.  Or the networking core gets to those
data indirectly by calling a callback.

Apparently the Linux IPv6 core needs to learn a little bit about RFC 3146.
But it doesn't need to (and should not) learn anything about the Linux
IEEE 1394 implementation, that's what I am trying to convey. :-)
-- 
Stefan Richter
-=====-===-= ---= -==--
http://arcgraph.de/sr/
--
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