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;
MIME-Version: 1.0
References: <MN2PR20MB29734588383A8699E6B700F3CA690@MN2PR20MB2973.namprd20.prod.outlook.com>
 <MN2PR20MB29730B2489C1A416BE8B7864CA690@MN2PR20MB2973.namprd20.prod.outlook.com>
In-Reply-To: <MN2PR20MB29730B2489C1A416BE8B7864CA690@MN2PR20MB2973.namprd20.prod.outlook.com>
From:   Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Mon, 21 Oct 2019 14:11:54 +0200
Message-ID: <CAKv+Gu8xVE+QwU39McGPsGRfx9PuoiHyHFY3fie4rDidhcSfYg@mail.gmail.com>
Subject: Re: Key endianness?
To:     Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>
Cc:     "linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
        "herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Mon, 21 Oct 2019 at 14:08, Pascal Van Leeuwen
<pvanleeuwen@verimatrix.com> 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, so relying on that is a mistake. Your code should do the
bitwise arithmetic explicitly to be portable.

> 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@vger.kernel.org <linux-crypto-owner@vger.kernel.org> On Behalf Of
> > Pascal Van Leeuwen
> > Sent: Monday, October 21, 2019 12:56 PM
> > To: linux-crypto@vger.kernel.org; herbert@gondor.apana.org.au
> > 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@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
>