netdev - Re: [PATCH net-next v4 1/4] ieee802154: add generic header handling routines

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:	Tue, 4 Mar 2014 23:49:33 +0100
From:	"Phoebe Buckheister" <phoebe.buckheister@...m.fraunhofer.de>
To:	"David Miller" <davem@...emloft.net>
Cc:	phoebe.buckheister@...m.fraunhofer.de, netdev@...r.kernel.org,
	linux-zigbee-devel@...ts.sourceforge.net
Subject: Re: [PATCH net-next v4 1/4] ieee802154: add generic header 
 handling routines

> Why have an intermediate copy when that's not necessary at all?  It
> seems like pure overhead to be.
>
> Furthermore, cpu's have byte-shifting load and store instructions
> which will be used if you make use of the 'p' versions of the endian
> swap functions, such as cpu_to_le16p().
>
> So it's going to cost basically nothing.

I didn't mean the runtime cost of any conversion that might happen, I was
thinking about how much these conversions would affect the code that uses
these header structs. While for the u16/u32 fields this might be not much,
it will be more for the hardware address fields since these are stored as
the little endian encoding of u64 field you get when reading the u8[8] as
a __be64. If I understand you correctly, these fields would also have to
be in network byte order in the header struct, introducing copy-and-swaps
in every upper layer that uses those addresses and making address matching
harder since memcmp won't work anymore.

What would be better here? Explicit endianness on all fields for
consistency and thus __le64 for EUI64 members with copy-swap functions to
convert those addresses into u8[8] where required, explicit endianness on
everything except addresses, or keeping it as is? I'm honestly not sure.

I want to note here that struct ieee802154_addr, which holds the address
information and is also used by BSD socket calls, has always used host
byte order for its own fields. This might itself be a huge mistake, but it
is relevant to this discussion.

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