> -----Original Message----- > From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > Sent: Monday, October 21, 2019 1:59 PM > To: Pascal Van Leeuwen <pvanleeuwen@xxxxxxxxxxxxxx> > Cc: linux-crypto@xxxxxxxxxxxxxxx; herbert@xxxxxxxxxxxxxxxxxxx > Subject: Re: Key endianness? > > 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. > Thanks for trying to help out, but that just gives me an "error: not an lvalue" from both sparse and GCC. But I'm probably doing it wrong somehow ... > > 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. > So these will need to be consistently handled using cpu_to_Xe32. > 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. > Depends a bit on the algorithm. Some keys are indeed defined as byte streams, in which case you have a point. Assuming you mean that the crypto API follows the byte order as defined by the algorithm spec. But sometimes the key data is actually a stream of _words_ (example: Chacha20) and then endianness _does_ matter. Same thing applies to things like nonces and initial counter values BTW. > 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. > Which still requires you to know the byte order as used by the API. > > > > 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) > I'm sure _someone_ can, I'm not so sure _I_ can ;-) Regards, Pascal van Leeuwen Silicon IP Architect, Multi-Protocol Engines @ Verimatrix www.insidesecure.com
