On Thu, 19 Sep 2019 at 12:43, Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> wrote: > > Hi Ard, > Hello Geert, > On Wed, Sep 18, 2019 at 9:59 PM Linux Kernel Mailing List > <linux-kernel@xxxxxxxxxxxxxxx> wrote: > > Commit: 724ecd3c0eb7040d423b22332a60d097e2666820 > > Parent: 20bb4ef038a97b8bb5c07d2a1125019a93f618b3 > > Refname: refs/heads/master > > Web: https://git.kernel.org/torvalds/c/724ecd3c0eb7040d423b22332a60d097e2666820 > > Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> > > AuthorDate: Tue Jul 2 21:41:20 2019 +0200 > > Committer: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > > 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@xxxxxxxxxx> > > Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> > > > --- 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@xxxxxxxxxxxxxx > > 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
