From patchwork Thu Jun 22 04:41:48 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Binoy Jayan X-Patchwork-Id: 106144 Delivered-To: patch@linaro.org Received: by 10.140.91.2 with SMTP id y2csp2273136qgd; Wed, 21 Jun 2017 21:42:39 -0700 (PDT) X-Received: by 10.84.225.18 with SMTP id t18mr752331plj.273.1498106559279; Wed, 21 Jun 2017 21:42:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498106559; cv=none; d=google.com; s=arc-20160816; b=G4sxSVkkxoZRR+R2iwuQaJQSSkkl8ZpSoZXN7EJ6/P7rsmJ5kSbSWqOPG0C8ubHbFk ZuSyvJteTn9obg0gc8HrbuWLiAbHMKkhGsgzRHseOxrE0WD9sXIIfbB56e6GQU6S6eTV gP9fsKeDFhWxOCl8O6foK84IVe1VBad8rV9H64Wl3/UnwHrtsLMJVzVhO+ba5cig1tOh KA+S6/yr8DVUAgG8tJOgJPaJr8+KXwf4Tq0ZXj1K9MGWt9IHkxU56BHWoLyKOR8KdCcC iWC19/aUzM5rFIR2NYxiX139VeUhY+dEeZAnTfs4Eu8swf1FKBW0VmjY8AP+qFBTaWD7 ncqQ== 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=hmzvFxeUW+cYQsI8iKo2xrLGo7YdkptUbhVw7XKoKNY=; b=kMqcD/PzQFLSZgFwDg1zw7d/+hfYML0RBFEeOYEPElHppya5hfUZMEBw/fjqmeYOzA y1Zy7LhIAGoD0hq1nX/6qTI8b6G4QsNhBJhsTtOt7PNKzYIDMDGvsrQtKCYyaC3KzkC7 FF+B05LuwUJIr6VATP/vfzWJjno8v12QAQ6Y6v6zJtKERSjTSDxpicPegrGJALVGbGFz 5zVXlZEgqmS5xZACqZFqZ3fVjHdLl7pff/MIojiBXINPRhX0DB4CWcOjXKUZAvIS5o9p /2zU6muQu6Iej4twkfTaef+YgVqL6hQTbrIqA8dAqh794XEqWw9BM3ATQMv5OBVzO1cF 4ETQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=J+hSTSyR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 o14si340760pli.540.2017.06.21.21.42.38; Wed, 21 Jun 2017 21:42:39 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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=J+hSTSyR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 S1752403AbdFVEmf (ORCPT + 25 others); Thu, 22 Jun 2017 00:42:35 -0400 Received: from mail-pf0-f179.google.com ([209.85.192.179]:33114 "EHLO mail-pf0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751236AbdFVEmd (ORCPT ); Thu, 22 Jun 2017 00:42:33 -0400 Received: by mail-pf0-f179.google.com with SMTP id e7so3496295pfk.0 for ; Wed, 21 Jun 2017 21:42:33 -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=hmzvFxeUW+cYQsI8iKo2xrLGo7YdkptUbhVw7XKoKNY=; b=J+hSTSyRy6EmL+KlGcts3VDBDZuTOS4Qw8q9oKblZ4xGVh60rvvz3hm62S7w7Y+cUK KM+CdF0uuaZklvJ2lxGAkM5Va/8UOWNWBnO+prv/NpShH8azHHm1rSUXOhCHIsuWLfaG VFtCbOECOfJieQ8E4VLFedExMICtJZG8EEp0o= 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=hmzvFxeUW+cYQsI8iKo2xrLGo7YdkptUbhVw7XKoKNY=; b=aVg6enyPKW5u2TQPjaVxfYrQAgMSzTxXjJEE6tRSMaIe4R3lEuXbuE62iTpYNtULjQ plpTXvUo3p6JJKwd4KFcRAyGn6TTQF+DCdNqKKjIHKUDEEnRN0Ed0RechiRBDQCr9uNt 8aWDAiKhmLAniftV0cw/rSNhTJdww7U5SmixyjflPe6F+Zf9ZDnZiuC6o4u/jvtvyMAv dLdgln7o2VmfM8VRR2h06LPvQtEeZvFa2XrNw2sTd+kUfptY/w5rC9AL8CES+NIjwH51 jELIOy+t/Vw8hS6/4mCu5m/G9bXCeVEfh3IS3wJAuDo4OJtdn0KtbfXb0AzeLAWobh/E 2gXg== X-Gm-Message-State: AKS2vOzJg3jrhw4eLSinKXIvGgceFSh9MwhI+xDjdGhdMU7SZ3qIe2vb rNBmWTYDirSQxCRj X-Received: by 10.84.229.5 with SMTP id b5mr800483plk.164.1498106552871; Wed, 21 Jun 2017 21:42:32 -0700 (PDT) Received: from blr-ubuntu-59.ap.qualcomm.com (blr-bdr-fw-01_globalnat_allzones-outside.qualcomm.com. [103.229.18.19]) by smtp.gmail.com with ESMTPSA id o13sm667635pfa.120.2017.06.21.21.42.29 (version=TLS1_1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 21 Jun 2017 21:42:32 -0700 (PDT) From: Binoy Jayan To: Mark Brown Cc: Arnd Bergmann , linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org, dm-devel@redhat.com, linux-raid@vger.kernel.org, Rajendra , Binoy Jayan Subject: [PATCH v6 0/2] IV Generation algorithms for dm-crypt Date: Thu, 22 Jun 2017 10:11:48 +0530 Message-Id: <1498106510-19793-1-git-send-email-binoy.jayan@linaro.org> X-Mailer: git-send-email 1.9.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org =============================================================================== dm-crypt optimization for larger block sizes =============================================================================== Currently, the iv generation algorithms are implemented in dm-crypt.c. The goal is to move these algorithms from the dm layer to the kernel crypto layer by implementing them as template ciphers so they can be used in relation with algorithms like aes, and with multiple modes like cbc, ecb etc. As part of this patchset, the iv-generation code is moved from the dm layer to the crypto layer and adapt the dm-layer to send a whole 'bio' (as defined in the block layer) at a time. Each bio contains the in memory representation of physically contiguous disk blocks. Since the bio itself may not be contiguous in main memory, the dm layer sets up a chained scatterlist of these blocks split into physically contiguous segments in memory so that DMA can be performed. One challenge in doing so is that the IVs are generated based on a 512-byte sector number. This infact limits the block sizes to 512 bytes. But this should not be a problem if a hardware with iv generation support is used. The geniv itself splits the segments into sectors so it could choose the IV based on sector number. But it could be modelled in hardware effectively by not splitting up the segments in the bio. Another challenge faced is that dm-crypt has an option to use multiple keys. The key selection is done based on the sector number. If the whole bio is encrypted / decrypted with the same key, the encrypted volumes will not be compatible with the original dm-crypt [without the changes]. So, the key selection code is moved to crypto layer so the neighboring sectors are encrypted with a different key. The dm layer allocates space for iv. The hardware drivers can choose to make use of this space to generate their IVs sequentially or allocate it on their own. This can be moved to crypto layer too. Postponing this decision until the requirement to integrate milan's changes are clear. Interface to the crypto layer - include/crypto/geniv.h More information on test procedure can be found in v1. Results of performance tests with software crypto in v5. The patch 'crypto: Multikey template for essiv' depends on the following patches by Gilad: MAINTAINERS: add Gilad BY as maintainer for ccree staging: ccree: add devicetree bindings staging: ccree: add TODO list staging: add ccree crypto driver Revisions: ---------- v1: https://patchwork.kernel.org/patch/9439175 v2: https://patchwork.kernel.org/patch/9471923 v3: https://lkml.org/lkml/2017/1/18/170 v4: https://patchwork.kernel.org/patch/9559665 v5: https://patchwork.kernel.org/patch/9669237 v5 --> v6: ---------- 1. Moved allocation of initialization vectors to the iv-generator 2. Few consmetic changes as the consequence of the above 3. Few logical to boolean expressions for faster calculation 4. Included multikey template for splitting keys. This needs testing with real hardware (juno with ccree) and also modification. It is only for testing and not for inclusion upstream. v4 --> v5 ---------- 1. Fix for the multiple instance issue in /proc/crypto 2. Few cosmetic changes including struct alignment 3. Simplified 'struct geniv_req_info' v3 --> v4 ---------- Fix for the bug reported by Gilad Ben-Yossef. The element '__ctx' in 'struct skcipher_request req' overflowed into the element 'struct scatterlist src' which immediately follows 'req' in 'struct geniv_subreq' and corrupted src. v2 --> v3 ---------- 1. Moved iv algorithms in dm-crypt.c for control 2. Key management code moved from dm layer to cryto layer so that cipher instance selection can be made depending on key_index 3. The revision v2 had scatterlist nodes created for every sector in the bio. It is modified to create only once scatterlist node to reduce memory foot print. Synchronous requests are processed sequentially. Asynchronous requests are processed in parallel and is freed in the async callback. 4. Changed allocation for sub-requests using mempool v1 --> v2 ---------- 1. dm-crypt changes to process larger block sizes (one segment in a bio) 2. Incorporated changes w.r.t. comments from Herbert. Binoy Jayan (2): crypto: Add IV generation algorithms crypto: Multikey template for essiv drivers/md/dm-crypt.c | 1940 +++++++++++++++++++++++++++----------- drivers/staging/ccree/Makefile | 2 +- drivers/staging/ccree/essiv.c | 777 +++++++++++++++ drivers/staging/ccree/essiv_sw.c | 1040 ++++++++++++++++++++ include/crypto/geniv.h | 46 + 5 files changed, 3251 insertions(+), 554 deletions(-) create mode 100644 drivers/staging/ccree/essiv.c create mode 100644 drivers/staging/ccree/essiv_sw.c create mode 100644 include/crypto/geniv.h -- Binoy Jayan