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>] [day] [month] [year] [list]
Message-ID: <416aa1ad0707260255h650468f5m67cef596523f949e@mail.gmail.com>
Date:	Thu, 26 Jul 2007 15:25:20 +0530
From:	"kalash nainwal" <kalash.nainwal@...il.com>
To:	netdev@...r.kernel.org
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: inconsistency in dev->hard_header() arguments?

The function is called like this- dev->hard_header(skb, dev, ptype,
dest_hw, src_hw, skb->len); where "skb->protocol" is same as "ptype",
but the former is expected to be in network byte order before calling
hard_header, while latter in host byte order (eth_header internally
does its own conversion of ptype). Is this deliberate? or a bug?

We've a driver, which sends pkt over ethernet. Here's the sample send routine-

my_eth_send(struct sk_buff * mp, struct net_device *dev, int linkno)
{
<snip>
        mp->protocol = link->ln_sap;
        mp->nh.raw = mp->data;
        dev->hard_header(mp, mp->dev, ntohs(link->ln_sap),
                dest_node->n_linkinfo[linkno].n_addr,
                src_node->n_linkinfo[linkno].n_addr,
                mp->len);
         dev_queue_xmit(mp);
}

We store the type field (i.e., link->ln_sap) in our driver in network
byte order only (as skb->protocol is expected to be in network byte
order), but as eth_header internally does the conversion again, we've
to un-convert it (for every outgoing pkt!!) unnecessarily. We can get
away with this by using two different variables for ptype- one in n/w
order, other in host order; but unless there's some hidden magic
behind the current behavior, I'd like to send a patch to fix this in
kernel. Or if you think it would touch too many files, might break too
many things...we can let it be.

Regards,
-Kalash
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ