On Mon, 21 Oct 2019 at 12:56, Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> wrote: > > 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? > In this case, just use (__force __Xe32*) to cast it to the correct type. This annotates the cast as being intentionally endian-unclean, and shuts up Sparse. > 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. > > crypto_aes_ctx uses CPU endianness for the round keys. In general, though, there is no such thing as endianness for a key that is declared as u8[], it is simply a sequence of bytes. If the hardware chooses to reorder those bytes for some reason, it is the responsibility of the driver to take care of that from the CPU side. > > 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. > > You can boot big endian kernels on MacchiatoBin, in case that helps (using u-boot, not EFI)
