From patchwork Tue Jun 20 09:28:53 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 105934 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp1273314qgd; Tue, 20 Jun 2017 02:33:16 -0700 (PDT) X-Received: by 10.98.222.195 with SMTP id h186mr29558460pfg.36.1497951196761; Tue, 20 Jun 2017 02:33:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497951196; cv=none; d=google.com; s=arc-20160816; b=Jt/PX9EtHMaVWnvi7Kwu2fLBcLL8uadz7gcVu3zcuyK8qdLi7kkFC0G2OpYTmVQngV OOEUjEP0dMzDlseJWplWl2PBZSgRJHxlm9EWmisRxoAQTPPXSgKoIkOl5fcqE4pE81X4 juSDqL+DJE3O3WmX1QQUqvjizdfIdiDtj+6dnKbhMRcef7QE/RKyQrp3OSys9DnY1lbU cNOoTd0cr1PNpSTCuqVAbJWY2h8gnQ9o3Q7bpHfOfj/t8CO+joGLRAAPJgnfcg6Huqf9 F8ig30BaC4h4SfigKjVtIimogLZOjXZ9AqoB/VBD5dGnN1JAD+C0XgnpyoAFuMj08WWp LorA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=CVLo/v7kt2CzC18pg2NBPWIx+tYb4guO9z3l6z5k8Nk=; b=FzHAp5Dopr2zEcvz3taGqVBI0sTCfKbnzJhr2ZDXaOrCZL6iNYYOPu064xMnjv8lW9 zoaetvRL+lUB9rhVGsa8zI2FDVHVpHPZe13txcoxcFgA0At2IRvDHY3FK2yiWBNLYVn0 FkM/nT9RAc3vREi20094QMTEySGDcBS0DlnmtCQkzDNdCR7mzArzoMeiFOi8UhvAcxPH 48WjKcobxO/VrsVyhyOtz9gS+JTBHYC5ImESXGX4qMzODmfwCWGArZPoxxGSW6kMSfze KemjdHvMQeJK7/m0ueaBnAKKj6XTi/DkRZHBlPXmyiTayB4QY33Mi4B1uLKsPb7+2CO9 S8yg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=GqRcQE6U; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r8si10112330pgr.331.2017.06.20.02.33.16; Tue, 20 Jun 2017 02:33:16 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.b=GqRcQE6U; spf=pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751898AbdFTJao (ORCPT + 1 other); Tue, 20 Jun 2017 05:30:44 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:36150 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751927AbdFTJ3F (ORCPT ); Tue, 20 Jun 2017 05:29:05 -0400 Received: by mail-wm0-f48.google.com with SMTP id m125so15863047wmm.1 for ; Tue, 20 Jun 2017 02:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=CVLo/v7kt2CzC18pg2NBPWIx+tYb4guO9z3l6z5k8Nk=; b=GqRcQE6U3th6MI75pcaI67FVejGJL2KdhczVYj5+r6XaLmZy51RHr0+HZIVpNQq71y CTpi71k/oA2m4ZAwyZseOz+PCcoLrXYNqTKmCJhoVD1ArgSqFoOxAExmim32P3SGbTrX ajbpT5q2GZtLZGS8I5t74zo1ISKFF6+wCVDZE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=CVLo/v7kt2CzC18pg2NBPWIx+tYb4guO9z3l6z5k8Nk=; b=ZF9zhxYbtPnhk2kvYGS9FYjpWWaIk7w2ejtE2ZvPsu+W0hfcrPgbBzXKfAHuCn52ra kswQo7Zm9o/cOqD5Me+0GSFIUyPVL8Tzh+auPqWkwrpPv3DQzOTZz2KR5ldylrHbzT7y qiPhEduDsCS1VC1Lqj4MnOOyGvwmOdY6CWvmROD9Rztb6NcPuZevepulzSR84BYesUBX yoVeSb1s5tx1QImYQh4l5mBOrLV01thxG8yFn2aI2MfCB31OnB+ZtHMH2JKQ8YOlzwnW bllnYXKwf8G+5c49H0FMDJ3Qmcujr6V8dkxy3+qMJX9LhrIS+nKui+MAkDKyY1n1C9/j q9Cg== X-Gm-Message-State: AKS2vOwfhMkjknyL8ze3iHtlKp98bznKCuoXJS7umsptR++lSM/o2qiy iErxS75+YGSPkpQ+WzO95A== X-Received: by 10.80.136.129 with SMTP id d1mr19980988edd.154.1497950943156; Tue, 20 Jun 2017 02:29:03 -0700 (PDT) Received: from localhost.localdomain (101-126-045-062.dynamic.caiway.nl. [62.45.126.101]) by smtp.gmail.com with ESMTPSA id a52sm6033452eda.44.2017.06.20.02.29.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 Jun 2017 02:29:02 -0700 (PDT) From: Ard Biesheuvel To: linux-crypto@vger.kernel.org Cc: herbert@gondor.apana.org.au, nico@linaro.org, ebiggers3@gmail.com, Ard Biesheuvel Subject: [PATCH v3 0/7] crypto: aes - allow generic AES to be omitted Date: Tue, 20 Jun 2017 11:28:53 +0200 Message-Id: <1497950940-24243-1-git-send-email-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.7.4 Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org The generic AES driver uses 16 lookup tables of 1 KB each, and has encryption and decryption routines that are fully unrolled. Given how the dependencies between this code and other drivers are declared in Kconfig files, this code is always pulled into the core kernel, even if it is usually superseded at runtime by accelerated drivers that exist for many architectures. This leaves us with 25 KB of dead code in the kernel, which is negligible in typical environments, but which is actually a big deal for the IoT domain, where every kilobyte counts. Also, the scalar, table based AES routines that exist for ARM, arm64, i586 and x86_64 share the lookup tables with AES generic, and may be invoked occasionally when the time-invariant AES-NI or other special instruction drivers are called in interrupt context, at which time the SIMD register file cannot be used. Pulling 16 KB of code and 9 KB of instructions into the L1s (and evicting what was already there) when a softirq happens to be handled in the context of an interrupt taken from kernel mode (which means no SIMD on x86) is also something that we may like to avoid, by falling back to a much smaller and moderately less performant driver. (Note that arm64 will be updated shortly to supply fallbacks for all SIMD based AES implementations, which will be based on the core routines [if they are accepted].) For the reasons above, this series refactors the way the various AES implementations are wired up, to allow the generic version in crypto/aes_generic.c to be omitted from the build entirely. Patch #1 removes some bogus 'select CRYPTO_AES' statement. Patch #2 introduces CRYPTO_AES_CORE and its implementation crypto/aes_core.c, which contains the existing key expansion routines, and default encrypt and decrypt routines that are not exposed as a crypto_cipher themselves, but can be pulled in by other AES drivers. These routines only depend on the two 256 byte Sboxes Patch #3 switches the fallback in the AES-NI code to the new, generic encrypt and decrypt routines so it no longer depends on the x86 scalar code or [transitively] on AES-generic. Patch #4 removes the local copy of the AES sboxes from the arm64 NEON driver, and switches to the ones exposed by the new AES core module instead. Patch #5 repurposes the CRYPTO_AES Kconfig symbol as an abstract symbol that indicates whether some implementation of AES needs to be available. The existing generic code is now controlled by CRYPTO_AES_GENERIC. Patch #6 updates the Kconfig help text to be more descriptive of what they actually control, rather than duplicating AES's wikipedia entry a number of times. Patch #7 updates the Kconfig logic so CRYPTO_AES_GENERIC can be disabled if any CRYPTO_AES dependencies are satisfied by the fixed time driver. v3: - fix big-endian issue in refactored fixed-time AES driver - improve Kconfig help texts - add patch #4 v2: - repurpose CRYPTO_AES and avoid HAVE_AES/NEED_AES Kconfig symbols - don't factor out tables from AES generic to be reused by per arch drivers, since the space saving is moderate (the generic code only), and the drivers weren't made to be small anyway Ard Biesheuvel (7): drivers/crypto/Kconfig: drop bogus CRYPTO_AES dependencies crypto: aes - refactor shared routines into separate core module crypto: x86/aes-ni - switch to generic fallback crypto: arm64/aes-neon - reuse Sboxes from AES core module crypto: aes - repurpose CRYPTO_AES and introduce CRYPTO_AES_GENERIC crypto: aes - add meaningful help text to the various AES drivers crypto: aes - allow generic AES to be replaced by fixed time AES arch/arm/crypto/Kconfig | 20 +- arch/arm64/crypto/Kconfig | 34 +- arch/arm64/crypto/aes-neon.S | 74 +---- arch/x86/crypto/aesni-intel_glue.c | 4 +- crypto/Kconfig | 161 ++++------ crypto/Makefile | 3 +- crypto/aes_core.c | 333 ++++++++++++++++++++ crypto/aes_generic.c | 178 ----------- crypto/aes_ti.c | 315 ++---------------- drivers/crypto/Kconfig | 13 +- include/crypto/aes.h | 6 + net/sunrpc/Kconfig | 3 +- 12 files changed, 486 insertions(+), 658 deletions(-) create mode 100644 crypto/aes_core.c -- 2.7.4