On Mon, 21 Oct 2019 at 14:08, Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> wrote: > > 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? The C spec does not define how packed bitfields are projected onto memory, so relying on that is a mistake. Your code should do the bitwise arithmetic explicitly to be portable. > 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 >
