linux-kernel - Re: crypto: aes - rename local routines to prevent future clashes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 19 Sep 2019 12:58:26 +0300
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: crypto: aes - rename local routines to prevent future clashes

On Thu, 19 Sep 2019 at 12:43, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>
> Hi Ard,
>

Hello Geert,

> On Wed, Sep 18, 2019 at 9:59 PM Linux Kernel Mailing List
> <linux-kernel@...r.kernel.org> wrote:
> > Commit:     724ecd3c0eb7040d423b22332a60d097e2666820
> > Parent:     20bb4ef038a97b8bb5c07d2a1125019a93f618b3
> > Refname:    refs/heads/master
> > Web:        https://git.kernel.org/torvalds/c/724ecd3c0eb7040d423b22332a60d097e2666820
> > Author:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
> > AuthorDate: Tue Jul 2 21:41:20 2019 +0200
> > Committer:  Herbert Xu <herbert@...dor.apana.org.au>
> > CommitDate: Fri Jul 26 14:52:03 2019 +1000
> >
> >     crypto: aes - rename local routines to prevent future clashes
> >
> >     Rename some local AES encrypt/decrypt routines so they don't clash with
> >     the names we are about to introduce for the routines exposed by the
> >     generic AES library.
> >
> >     Signed-off-by: Ard Biesheuvel <ard.biesheuvel@...aro.org>
> >     Signed-off-by: Herbert Xu <herbert@...dor.apana.org.au>
>
> > --- a/crypto/aes_generic.c
> > +++ b/crypto/aes_generic.c
> > @@ -1332,7 +1332,7 @@ EXPORT_SYMBOL_GPL(crypto_aes_set_key);
> >         f_rl(bo, bi, 3, k);     \
> >  } while (0)
> >
> > -static void aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
> > +static void crypto_aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
> >  {
> >         const struct crypto_aes_ctx *ctx = crypto_tfm_ctx(tfm);
>
> Looking ay the bloat-o-meter output:
>
> crypto_aes_encrypt                             -    3158   +3158
> crypto_aes_decrypt                             -    3154   +3154
> aes_decrypt                                 3154    1276   -1878
> aes_encrypt                                 3158    1270   -1888
>
> Can't this just call aes_encrypt() now?
> CONFIG_CRYPTO_AES already selects CRYPTO_LIB_AES?
> Or does the latter has less features (it's smaller, too)?
>

The latter is smaller but slower, especially for decryption. I am not
sure whether the output accounts for this, but the actual space saving
is in the lookup tables, not in the code itself (16k vs 512 bytes)

Also, we removed the x86 ASM implementations of scalar AES, since the
compiler actually produces faster code, but this also uses the
'bloated' version above.

To make matters more interesting, the fact that the tables are much
smaller means that the new code is assumed to be much less susceptible
to known timing-related vulnerabilities in table based AES.

So to summarize, platforms that don't have special instructions or
SIMD based AES implementations will need the original aes-generic
driver, or we will cause significant performance regression,
especially when decrypting. The library interface is more intended as
a) a base layer for other AES implementations, and b) a reasonable
option for non-performance critical code.



> >         u32 b0[4], b1[4];
> > @@ -1402,7 +1402,7 @@ static void aes_encrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
> >         i_rl(bo, bi, 3, k);     \
> >  } while (0)
> >
> > -static void aes_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
> > +static void crypto_aes_decrypt(struct crypto_tfm *tfm, u8 *out, const u8 *in)
> >  {
> >         const struct crypto_aes_ctx *ctx = crypto_tfm_ctx(tfm);
>
> aes_decrypt()?
>
> >         u32 b0[4], b1[4];
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds