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
| ||
|
Date: Mon, 25 Jul 2011 03:01:09 -0700 (PDT) From: David Miller <davem@...emloft.net> To: roland@...nel.org CC: linux-rdma@...r.kernel.org, netdev@...r.kernel.org Subject: [PATCH 0/7] More sane neigh infrastructure Roland, this is a first pass at the kind of thing I was talking about with you last week. ATM and Infiniband both need to do their own kind of signaling, either in place of (ATM) or in addition to (IPoIB) the generic ARP negotiation. ATM wants to push everything to a userspace atmarpd daemon, and override all of the usual ARP signalling. It replaces the neigh_table used by ARP completely in order to accomplish this. IPoIB triggers it's signalling by hooking in at transmit time, and adding a neigh parms destruction hook to free up and release it's private per-neigh state. I think both cases can be consolidated into one kind of scheme, and these patches provide the infrastructure and convert ATM over as an example. Devices provide up to three things: 1) netdev->neighpriv_len, length of per-neighbour device private state, accessible via neighbour_priv(neigh) 2) net_device_ops->ndo_neigh_construct(), invoked right after neigh_tbl->constructor(), can fail 3) net_device_ops->ndo_neigh_destroy(), invoked right before we release neigh->parms and kfree_rcu() the neigh object. It could return errors but I'm not checking for them currently and I can't think what we could possibly do in response at this point in the code. Maybe this gets changed to return "void" eventually. As a result ATM CLIP no longer overrides the IPV4 ARP table, and I'm convinced IPoIB could behave similarly, override the neigh_ops in a device neigh constructor, and avoid all of the hooks at transmit time and instead trigger the key signalling at neigh->output and friends. If IPoIB can get converted to this new stuff, then we can get rid of the ->ndo_neigh_setup() netdev op which only exists to facilitate IPoIB hooking in a destructor for it's neigh state. -- 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
Powered by blists - more mailing lists