On Thu, 10 Dec 2020 at 12:14, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, Dec 10, 2020 at 08:30:47AM +0100, Ard Biesheuvel wrote:
> >
> > I would argue that these are orthogonal. My patch improves both the
> > accelerated and the fallback path, given that the latter does not have
> > to walk the input data twice anymore, and go through 3 layers of
> > templates and the associated indirect calls for each 16 bytes of
> > input.
>
> As I told your before, your patch introduces a new model into aesni
> that is different to every other algorithm there for the sole purpose
> of catering for legacy hardware in a subsystem that refuses to do
> the right thing.
>
> That is not acceptable.
>
OK, I will stop whining about CCM, apologies if this is getting tedious.
But we should probably start policing this a bit more. For instance, we now have
drivers/net/macsec.c:
/* Pick a sync gcm(aes) cipher to ensure order is preserved. */
tfm = crypto_alloc_aead("gcm(aes)", 0, CRYPTO_ALG_ASYNC);
(btw the comment is bogus, right?)
TLS_SW does the same thing in net/tls/tls_device_fallback.c.
So it is not only CCM in the 802.11 layer, there are now other places
where we end up using a sub-optimal algorithm (and less secure if
table based AES or GHASH end up being used) just to avoid a potential
fallback which is not even as bad as the fallback we will actually end
up with when the crypto API synthesizes it from the GCM, CTR and GHASH
templates/drivers.
Async is obviously needed for h/w accelerators, but could we perhaps
do better for s/w SIMD algorithms? Those are by far the most widely
used ones.
