And now that we've opened Pandora's box of "ellendianness" (as we say here - a combination of the Dutch word "ellende", for misery, and endianness ;-): The inside-secure driver uses several packed bitfield structures (that are actually used directly by the little-endian hardware) What happens to these on a big-endian machine? I've seen examples that hint at having to define the bits in reverse order on big-endian machines, which would require a big "#ifdef LITTLE_ENDIAN / #else" around the whole struct definition. And then on top of that I'll probably still have to swap the bytes within words to get those into the correct order towards the HW. Which is not very convenient for fields crossing byte boundaries. (I'd probably want to use the byte swapping facilities of my HW for that and not the CPU) Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com > -----Original Message----- > From: linux-crypto-owner@xxxxxxxxxxxxxxx <linux-crypto-owner@xxxxxxxxxxxxxxx> On Behalf Of > Pascal Van Leeuwen > Sent: Monday, October 21, 2019 12:56 PM > To: linux-crypto@xxxxxxxxxxxxxxx; herbert@xxxxxxxxxxxxxxxxxxx > Subject: RE: Key endianness? > > Another endianness question: > > I have some data structure that can be either little or big endian, > depending on the exact use case. Currently, I have it defined as u32. > This causes sparse errors when accessing it using cpu_to_Xe32() and > Xe32_to_cpu(). > > Now, for the big endian case, I could use htonl()/ntohl() instead, > but this is inconsistent with all other endian conversions in the > driver ... and there's no little endian alternative I'm aware of. > So I don't really like that approach. > > Alternatively, I could define a union of both a big and little > endian version of the data but that would require touching a lot > of legacy code (unless I use a C11 anonymous union ... not sure > if that would be allowed?) and IMHO is a bit silly. > > Is there some way of telling sparse to _not_ check for "correct" > use of these functions for a certain variable? > > Regards, > Pascal van Leeuwen > Silicon IP Architect, Multi-Protocol Engines @ Verimatrix > www.insidesecure.com > > > -----Original Message----- > > From: Pascal Van Leeuwen > > Sent: Monday, October 21, 2019 11:04 AM > > To: linux-crypto@xxxxxxxxxxxxxxx; herbert@xxxxxxxxxxxxxxxxxxx > > Subject: Key endianness? > > > > Herbert, > > > > I'm currently busy fixing some endianness related sparse errors reported > > by this kbuild test robot and this triggered my to rethink some endian > > conversion being done in the inside-secure driver. > > > > I actually wonder what the endianness is of the input key data, e.g. the > > "u8 *key" parameter to the setkey function. > > > > I also wonder what the endianness is of the key data in a structure > > like "crypto_aes_ctx", as filled in by the aes_expandkey function. > > > > Since I know my current endianness conversions work on a little endian > > CPU, I guess the big question is whether the byte order of this key > > data is _CPU byte order_ or always some _fixed byte order_ (e.g. as per > > algorithm specification). > > > > I know I have some customers using big-endian CPU's, so I do care, but > > I unfortunately don't have any platform available to test this with. > > > > Regards, > > Pascal van Leeuwen > > Silicon IP Architect, Multi-Protocol Engines @ Verimatrix > > www.insidesecure.com
