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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 12 Jan 2013 11:54:47 +0100
From:	Stephan Gatzka <stephan.gatzka@...il.com>
To:	Stefan Richter <stefanr@...6.in-berlin.de>
CC:	linux1394-devel@...ts.sourceforge.net, yoshfuji@...ux-ipv6.org,
	netdev@...r.kernel.org
Subject: Re: IPv6 over firewire

> But if a new callback is needed, it doesn't have to burden the kernel much:
>
>    - In the linux-kernel OOP model, there are mandatory methods as well
>      as optional methods.  A new method for RFC 3146 Neighbor Discovery
>      should of course be an optional one.
>
>    - There is a downside to optional methods:  The core code which may
>      have to use the method first needs to do a NULL check of the
>      method's function pointer or needs to check a correlated
>      capabilities flag or something like that.  Such additional checks
>      are undesirable in hot paths, but I suppose IPv6 Neighbor Discovery
>      is not a particularly hot path.

Yes, that should be true.

>
>    - There is another downside:  Each new driver method increases the
>      memory footprint of instances of respective function pointer tables
>      by 4 or 8 bytes.

I can't imagine that this is a show stopper. How many instances of 
struct netdev do we have o a typical system? I guess not the much.

>
> Both downsides can be countered somewhat by enclosing the respective
> code into #ifdef CONFIG_RFC3146_NDISC...#endif and have something like
>      select RFC3146_NDISC if IPV6 = y || (IPV6 = m && FIREWIRE_NET = m)
> in the "config FIREWIRE_NET" section.
>
> But the new callback (if one is really needed) doesn't have to be a driver
> method.  It could also look about like this:
>
>      include/net/ndisc.h:
>      -extern struct ndisc_options *ndisc_parse_options(u8 *opt, int opt_len,
>      -		struct ndisc_options *ndopts);
>      +extern struct ndisc_options *__ndisc_parse_options(u8 *opt,
>      +		int opt_len, struct ndisc_options *ndopts,
>      +		whatever_type *callback);
>      +
>      +static inline struct ndisc_options *ndisc_parse_options(u8 *opt,
>      +		int opt_len, struct ndisc_options *ndopts)
>      +{
>      +	return __ndisc_parse_options(opt, len, ndopts, NULL);
>      +}
>
>      net/ipv6/ndisc.c:
>      -struct ndisc_options *ndisc_parse_options(u8 *opt, int opt_len,
>      -		struct ndisc_options *ndopts)
>      +struct ndisc_options *__ndisc_parse_options(u8 *opt, int opt_len,
>      +		struct ndisc_options *ndopts, whatever_type *callback)
>       {
>
> 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?

> 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.

Regards,

Stephan


-- 
Welchen Unterschied gibt es zwischen einem toten Hund auf der
Straße und einer überfahrenen Bratsche auf der Straße? Vor dem
toten Hund gibt es Bremsspuren.
--
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