> -----Original Message----- > From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > Sent: Monday, October 21, 2019 2:12 PM > To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > Cc: linux-crypto@xxxxxxxxxxxxxxx; herbert@xxxxxxxxxxxxxxxxxxx > Subject: Re: Key endianness? > > 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, > Yes, I know that. But GCC may still provide guarantees, I don't know. It's not my code, it's legacy code that was already there, which I try to touch as little as possible. (I already decided I didn't like it just based on the results of running it through Compiler Explorer - not very efficient ...) > so relying on that is a mistake. Your code should do the > bitwise arithmetic explicitly to be portable. > Yeah, probably. Problem is these data structures are used everywhere. So getting the changes through the whole review process would just be too painful. It's been like this for years and so far it worked just fine (I guess). So I'd prefer a solution that requires minimal changes to existing code but would still be guaranteed to work on both big and little endian machines, assuming you use GCC (or Clang?) as the compiler. > > 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 > > Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
