RE: Key endianness?

[Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>]

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@vger.kernel.org; herbert@gondor.apana.org.au
> 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