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>
In-Reply-To: <MN2PR20MB29734588383A8699E6B700F3CA690@MN2PR20MB2973.namprd20.prod.outlook.com>
From:   Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Mon, 21 Oct 2019 13:59:24 +0200
Message-ID: <CAKv+Gu8CvoaTCBxWjd9f=CtcK8GkgJkhRgYGjUHy3MqRKhezEg@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 12:56, Pascal Van Leeuwen
<pvanleeuwen@verimatrix.com> 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@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.
> >

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)