Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20201201194556.5220-1-ardb@kernel.org> <20201201215722.GA31941@gondor.apana.org.au>
 <CAMj1kXHb27ugTWuQZhPD0DvjtgYC8t_pj+igqK7dNfh+WsUS4w@mail.gmail.com> <20201201220431.GA32072@gondor.apana.org.au>
In-Reply-To: <20201201220431.GA32072@gondor.apana.org.au>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Tue, 1 Dec 2020 23:12:32 +0100
Message-ID: <CAMj1kXGO+kbZ+2VmUQKxLYos2nR5vqZKjengxPxPjSXudG-zLw@mail.gmail.com>
Subject: Re: [PATCH v2] crypto: aesni - add ccm(aes) algorithm implementation
To:     Herbert Xu <herbert@gondor.apana.org.au>
Cc:     Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
        Ben Greear <greearb@candelatech.com>,
        Steve deRosier <derosier@cal-sierra.com>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Tue, 1 Dec 2020 at 23:04, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>
> On Tue, Dec 01, 2020 at 11:01:57PM +0100, Ard Biesheuvel wrote:
> >
> > This is not the first time this has come up. The point is that CCMP in
> > the wireless stack is not used in 99% of the cases, given that any
> > wifi hardware built in the last ~10 years can do it in hardware. Only
> > in exceptional cases, such as Ben's, is there a need for exercising
> > this interface.
>
> Either it matters or it doesn't.  If it doesn't matter why are we
> having this dicussion at all? If it does then fixing just one
> direction makes no sense.
>

What do you mean by just one direction? Ben just confirmed a
substantial speedup for his use case, which requires the use of
software encryption even on hardware that could support doing it in
hardware, and that software encryption currently only supports the
synchronous interface.

Even if it is nicer in theory, I don't see the point of implementing
support for the asynchronous interface, given that nobody is going to
wire up a AES accelerator to a wifi controller.

> > Also, care to explain why we have synchronous AEADs in the first place
> > if they are not supposed to be used?
>
> Sync AEADs would make sense if you were dealing with a very small
> amount of data, e.g., one block.
>

Why? The processing occurs in *exactly* the same way, given that the
wifi stack never calls into the AEAD from a context where the FPU is
unavailable. So we basically have to choose between a non-SIMD
fallback path that never gets exercised, or a SIMD async helper that
always relays the request directly, and never queues it for
asynchronous completion.

IOW, we are arguing a theoretical difference here, and the code paths
that actually get exercised are 100% the same.