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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 20 May 2019 19:32:29 -0600 From: Subash Abhinov Kasiviswanathan <subashab@...eaurora.org> To: Alex Elder <elder@...aro.org> Cc: arnd@...db.de, david.brown@...aro.org, agross@...nel.org, davem@...emloft.net, bjorn.andersson@...aro.org, ilias.apalodimas@...aro.org, cpratapa@...eaurora.org, syadagir@...eaurora.org, evgreen@...omium.org, benchan@...gle.com, ejcaruso@...gle.com, netdev@...r.kernel.org, linux-arm-msm@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 1/8] net: qualcomm: rmnet: fix struct rmnet_map_header >> If the above illustration is supposed to be in network byte order, >> then it is wrong. The documentation has the definition for the MAP >> packet. > > Network *bit* order is irrelevant to the host. Host memory is > byte addressable only, and bit 0 is the low-order bit. > >> Packet format - >> >> Bit 0 1 2-7 8 - 15 16 >> - 31 >> Function Command / Data Reserved Pad Multiplexer ID >> Payload length >> Bit 32 - x >> Function Raw Bytes > > I don't know how to interpret this. Are you saying that the low- > order bit of the first byte is the command/data flag? Or is it > the high-order bit of the first byte? > > I'm saying that what I observed when building the code was that > as originally defined, the cd_bit field was the high-order bit > (bit 7) of the first byte, which I understand to be wrong. > > If you are telling me that the command/data flag resides at bit > 7 of the first byte, I will update the field masks in a later > patch in this series to reflect that. > Higher order bit is Command / Data. >> The driver was written assuming that the host was running ARM64, so >> the structs are little endian. (I should have made it compatible >> with big and little endian earlier so that is my fault). > > Little endian and big endian have no bearing on the host's > interpretation of bits within a byte. > > Please clarify. I want the patches to be correct, and what > you're explaining doesn't really straighten things out for me. > > -Alex Can't this bitfields just be used similar to how struct tcphdr & iphdr are currently defined. That way, you dont have to make these many changes. diff --git a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h index 884f1f5..302d1db 100644 --- a/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h +++ b/drivers/net/ethernet/qualcomm/rmnet/rmnet_map.h @@ -40,9 +40,17 @@ enum rmnet_map_commands { }; struct rmnet_map_header { +#if defined(__LITTLE_ENDIAN_BITFIELD) u8 pad_len:6; u8 reserved_bit:1; u8 cd_bit:1; +#elif defined (__BIG_ENDIAN_BITFIELD) + u8 cd_bit:1; + u8 reserved_bit:1; + u8 pad_len:6; +#else +#error "Please fix <asm/byteorder.h>" +#endif u8 mux_id; __be16 pkt_len; } __aligned(1); -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Powered by blists - more mailing lists