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: <20191002141713.31189-1-ard.biesheuvel@linaro.org>
 <20191002141713.31189-19-ard.biesheuvel@linaro.org> <20191004140057.GB114360@zx2c4.com>
In-Reply-To: <20191004140057.GB114360@zx2c4.com>
From:   Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Fri, 4 Oct 2019 16:11:59 +0200
Message-ID: <CAKv+Gu-iyWkWcodh7PBqPcbH-NhDGQ+v4YzvrO8zO1q9fLG0OA@mail.gmail.com>
Subject: Re: [PATCH v2 18/20] crypto: arm/Curve25519 - wire up NEON implementation
To:     "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc:     "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@vger.kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        David Miller <davem@davemloft.net>,
        Greg KH <gregkh@linuxfoundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Samuel Neves <sneves@dei.uc.pt>,
        Dan Carpenter <dan.carpenter@oracle.com>,
        Arnd Bergmann <arnd@arndb.de>,
        Eric Biggers <ebiggers@google.com>,
        Andy Lutomirski <luto@kernel.org>,
        Will Deacon <will@kernel.org>, Marc Zyngier <maz@kernel.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Martin Willi <martin@strongswan.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Fri, 4 Oct 2019 at 16:01, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> On Wed, Oct 02, 2019 at 04:17:11PM +0200, Ard Biesheuvel wrote:
> > +bool curve25519_arch(u8 out[CURVE25519_KEY_SIZE],
> > +                  const u8 scalar[CURVE25519_KEY_SIZE],
> > +                  const u8 point[CURVE25519_KEY_SIZE])
> > +{
> > +     if (!have_neon || !crypto_simd_usable())
> > +             return false;
> > +     kernel_neon_begin();
> > +     curve25519_neon(out, scalar, point);
> > +     kernel_neon_end();
> > +     return true;
> > +}
> > +EXPORT_SYMBOL(curve25519_arch);
>
> This now looks more like the Zinc way of doing things, with the _arch
> function returning true or false based on whether or not the
> implementation was available, allowing the generic implementation to
> run.
>
> I thought, from looking at the chacha commits earlier, you had done away
> with that style of things in favor of weak symbols, whereby the arch
> implementation would fall back to the generic one, instead of the other
> way around?

This will still use weak symbols, and so the NEON code is built into
its own module, which may fail to load or be blacklisted. Note that my
v3 working branch has already deviated a bit from the code here.

The difference between blake2s and curve25519 on the one hand and
chacha and poly on the other is that in the latter case, I am exposing
existing code via the library interface that is already being used via
the crypto API as well, which means that we have already duplicated
some of the boilerplate needed for, e.g., the init/update/final
interfaces.

blake2s and curve25519 are new to the kernel, and so we are not
exposing the same code via the shash interface and the library
interface at the same time. Taking blake2s as an example, there is a
core compress() transformation which gets overridden, while everything
else is provided by the base library.

In summary, it differs per library what the best approach is.