Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
To:     "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>
Subject: RE: Key endianness?
Thread-Topic: Key endianness?
Thread-Index: AdWH7WiyGB6aVNy7SJOkTaAoiPGHOgADxdEg
Date:   Mon, 21 Oct 2019 10:55:56 +0000
Message-ID: <MN2PR20MB29734588383A8699E6B700F3CA690@MN2PR20MB2973.namprd20.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: verimatrix.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5947232b-c8bc-4765-309b-08d756154020
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2019 10:55:56.3919
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: dcb260f9-022d-4495-8602-eae51035a0d0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Qs0y8ze0Pxoh1eko244stbn0DlcAbf5g91jg9/aOWRglWQ4It9jSwiO1mxt1nZgMxrBWsnddif/jPZHxComyPt3qtykpjrpkkacxWvDaVac=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR20MB2656
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-crypto.vger.kernel.org>
X-Mailing-List: linux-crypto@vger.kernel.org

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?
>=20
> Herbert,
>=20
> 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.
>=20
> I actually wonder what the endianness is of the input key data, e.g. the
> "u8 *key" parameter to the setkey function.
>=20
> 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.
>=20
> 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).
>=20
> 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.
>=20
> Regards,
> Pascal van Leeuwen
> Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
> www.insidesecure.com