Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2516502imm; Mon, 28 May 2018 09:33:42 -0700 (PDT) X-Google-Smtp-Source: AB8JxZqXgL3hCaJcfaqpdd8cWtDnpX5mfHkPP9t32aTmzaUJau1xxxKvBVr4uSiGh7z1iqDRB6Ai X-Received: by 2002:a17:902:2f84:: with SMTP id t4-v6mr14677032plb.24.1527525222482; Mon, 28 May 2018 09:33:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527525222; cv=none; d=google.com; s=arc-20160816; b=P1WXRxQ1Su8cDZYc6tTAjr1cXNQrI6I8naeFfkw71fZU/T2ytHo5a3GUuS3SxE8UPy 9OGT7WizV7P2sy9/rphBvWVEmLN6yjV97rD4NUTAj3XuNdblMDbm/Zk5a11nRQnRYuti 1V+CcxP9uaZ8kuec6Nd6ySYTieNcMAYi4HjmpUA1gLSUyWJFRO6hzOgT9DVjZR9EFuWW lQxLsn36g9cwTfiPvLbGxYGYITVMjqE7fvEUmkYihTuzaHgADIjVCsnrHL+4/ojOvc4S CkNf5gST5eB+MF+hJw43eitt7UjgtTfXZo7iFNVG75XU8yxvfvoNWTJsqknOVX+/lLwv 3xuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=rKF04iIyGL1zdDdEqf1nmJ4HJP3k58SeJKaxuCa5GuU=; b=xOiPANf/L6/Rnbq+PYusbVOAq/TkLHGiVGNtL8rTbT8+1QENFQtyDbjfspklyoXtZj Ev9FzW0UMCn66V8/7OPPE9LZXfegmGScfrK3Oi4C5gRVfMEB6KlBgQ5buP7UouQipRuQ ktao5D8rzQkRUFfm1aumE4+spBBtI0YSCqA1MurtOBRVmv01GsKBzlDHS51cwFxqyQcg tN2p20evBjZxkJJ65tDvVre+m/CBpcASsc/D4JWLl0RFQc5jHmyP/ilRUSULR9wsGYch dDj8naKVziqStLgaC5/+/aSI++Rnlk8zU3Pru3U3LA47Os1G94r2rO8A1y+Pab3bjdwv lklw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=JZ1d88Sp; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t1-v6si24151699pgr.681.2018.05.28.09.33.27; Mon, 28 May 2018 09:33:42 -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=@gmail.com header.s=20161025 header.b=JZ1d88Sp; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S940165AbeE1QdC (ORCPT + 99 others); Mon, 28 May 2018 12:33:02 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:55660 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936654AbeE1Qcv (ORCPT ); Mon, 28 May 2018 12:32:51 -0400 Received: by mail-wm0-f68.google.com with SMTP id a8-v6so33480562wmg.5 for ; Mon, 28 May 2018 09:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rKF04iIyGL1zdDdEqf1nmJ4HJP3k58SeJKaxuCa5GuU=; b=JZ1d88Sp3gC8GrgbAoqF9Sscuim0qfykkwOrQFS7C71EeFbXMsZc/t79dCNYGtWLjq f0jy9RS6hParZ+mmMWZ3IouVusnKjKatawy0ddlMtVQV/M1p1vDdtUgONjFmsVWqP78I Kzd4zPwabIS1SX7Hekfzsel2FxeAUQgdCPBN74iaj5PyA6SPJG0D3kNcDwk4xxdSf7Eb YPh5Q92T5Azhw6u/wXGY3dKemBwXKPLrSCdDQ1bwu+8lZIh1Xwf+f3UfKBIkZX746tht wJN+cB25Ss/yHAlAmBptrpJpEBt5yF09Tywap5BhGjd9rW0Xt09YaOO7A+zqRiTZOQfh W69w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rKF04iIyGL1zdDdEqf1nmJ4HJP3k58SeJKaxuCa5GuU=; b=hjZfFmmig9LiyNPKdrdQGeLrlL5n1ev/+pN6/+CGJwlTKDbUqEbm/cORopqx/T9DXK MkjnIyVPN3WgLRI7AExtrCO9MsO4/J8Uj0pWBVT2p8QXau89c+GsWCIQ0/eOxV7sVopM tOXIs4xd0dRS1kxNlEUBgWlVnfMjdvqQQzXz8Nl3k79MIVi67lPVi83G5pgqtYeSNcjZ qfjG8QsQwJZICi8KZwWrJ2EuEExe7W0IyDPSIaYNc7vKB+q5iFARNP45R4mvil5dY1Im 7bZQOUmb5CfkcNThBuesvJGO7+i5SWvbfWryhl4suhEubg3oQPsONPuUZ6gxIt6oQrt8 2ofQ== X-Gm-Message-State: ALKqPwcufs/KjdOGfbG4G4Bg8XLHeCAWuItmYtpoXIK9wjaLRONoosiA SvQWRefCKLEqpburFlIiDCs= X-Received: by 2002:a1c:30ce:: with SMTP id w197-v6mr8108344wmw.22.1527525169704; Mon, 28 May 2018 09:32:49 -0700 (PDT) Received: from [192.168.8.100] ([89.24.52.31]) by smtp.gmail.com with ESMTPSA id o2-v6sm11704997wmo.24.2018.05.28.09.32.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 May 2018 09:32:48 -0700 (PDT) Subject: Re: [PATCH] md: dm-crypt: Add Inline Encryption support for dmcrypt To: Ladvine D Almeida , Alasdair Kergon , Mike Snitzer Cc: linux-kernel@vger.kernel.org, Manjunath M Bettegowda , Prabu Thangamuthu , Tejas Joglekar , device-mapper development References: From: Milan Broz Message-ID: <7a510610-9133-39aa-6841-3925c532f3c0@gmail.com> Date: Mon, 28 May 2018 18:32:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/28/2018 03:01 PM, Ladvine D Almeida wrote: > > This patch adds new option > -- perform_inline_encrypt > that set the option inside dmcrypt to use inline encryption for > the configured mapping. I want to introduce inline encryption support > in the UFS Host Controller driver. The usage of the same for accomplishing > the Full Disk Encryption is done by the following changes in the > dmcrypt subsystem: > - New function crypt_inline_encrypt_submit() is added to the > dmcrypt which associate the crypto context to the bios which > are submitted by the subsystem. > - Successful configuration for the inline encryption will result in > the crypto transformation job being bypassed in the dmcrypt layer and the > actual encryption happens inline to the block device. I am not sure this is a good idea. Dm-crypt should never ever forward plaintext sector to underlying device. And you do not even check that your hw is available in the underlying device! If you want to use dm-crypt, write a crypto API driver for your crypto hw that defines specific cipher and let dm-crypt use this cipher (no patches needed in this case!) If I read the patch correctly, you do not check any parameters for compatibility with your hw support (cipher, mode, IV algorithm, key length, sector size ...) It seems like if the "perform_inline_encrypt" option is present, you just submit the whole bio to your code with new INLINE_ENCRYPTION bit set. What happens, if the cipher in table is different from what your hw is doing? Milan > Another patch set is sent to the block layer community for > CONFIG_BLK_DEV_INLINE_ENCRYPTION config, which enables changes in the > block layer for adding the bi_ie_private variable to the bio structure. > > Signed-off-by: Ladvine D Almeida > --- > drivers/md/dm-crypt.c | 55 +++++++++++++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 53 insertions(+), 2 deletions(-) > > diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c > index 44ff473..a9ed567 100644 > --- a/drivers/md/dm-crypt.c > +++ b/drivers/md/dm-crypt.c > @@ -39,6 +39,7 @@ > #include > > #define DM_MSG_PREFIX "crypt" > +#define REQ_INLINE_ENCRYPTION REQ_DRV > > /* > * context holding the current state of a multi-part conversion > @@ -125,7 +126,8 @@ struct iv_tcw_private { > * and encrypts / decrypts at the same time. > */ > enum flags { DM_CRYPT_SUSPENDED, DM_CRYPT_KEY_VALID, > - DM_CRYPT_SAME_CPU, DM_CRYPT_NO_OFFLOAD }; > + DM_CRYPT_SAME_CPU, DM_CRYPT_NO_OFFLOAD, > + DM_CRYPT_INLINE_ENCRYPT }; > > enum cipher_flags { > CRYPT_MODE_INTEGRITY_AEAD, /* Use authenticated mode for cihper */ > @@ -215,6 +217,10 @@ struct crypt_config { > > u8 *authenc_key; /* space for keys in authenc() format (if used) */ > u8 key[0]; > +#ifdef CONFIG_BLK_DEV_INLINE_ENCRYPTION > + void *ie_private; /* crypto context for inline enc drivers */ > + int key_cfg_idx; /* key configuration index for inline enc */ > +#endif > }; > > #define MIN_IOS 64 > @@ -1470,6 +1476,20 @@ static void crypt_io_init(struct dm_crypt_io *io, struct crypt_config *cc, > atomic_set(&io->io_pending, 0); > } > > +#ifdef CONFIG_BLK_DEV_INLINE_ENCRYPTION > +static void crypt_inline_encrypt_submit(struct crypt_config *cc, > + struct dm_target *ti, struct bio *bio) > +{ > + bio_set_dev(bio, cc->dev->bdev); > + if (bio_sectors(bio)) > + bio->bi_iter.bi_sector = cc->start + > + dm_target_offset(ti, bio->bi_iter.bi_sector); > + bio->bi_opf |= REQ_INLINE_ENCRYPTION; > + bio->bi_ie_private = cc->ie_private; > + generic_make_request(bio); > +} > +#endif > + > static void crypt_inc_pending(struct dm_crypt_io *io) > { > atomic_inc(&io->io_pending); > @@ -1960,6 +1980,9 @@ static int crypt_setkey(struct crypt_config *cc) > > /* Ignore extra keys (which are used for IV etc) */ > subkey_size = crypt_subkey_size(cc); > +#ifdef CONFIG_BLK_DEV_INLINE_ENCRYPTION > + cc->key_cfg_idx = -1; > +#endif > > if (crypt_integrity_hmac(cc)) { > if (subkey_size < cc->key_mac_size) > @@ -1978,10 +2001,19 @@ static int crypt_setkey(struct crypt_config *cc) > r = crypto_aead_setkey(cc->cipher_tfm.tfms_aead[i], > cc->key + (i * subkey_size), > subkey_size); > - else > + else { > r = crypto_skcipher_setkey(cc->cipher_tfm.tfms[i], > cc->key + (i * subkey_size), > subkey_size); > +#ifdef CONFIG_BLK_DEV_INLINE_ENCRYPTION > + if (r > 0) { > + cc->key_cfg_idx = r; > + cc->ie_private = cc->cipher_tfm.tfms[i]; > + r = 0; > + } > +#endif > + } > + > if (r) > err = r; > } > @@ -2654,6 +2686,10 @@ static int crypt_ctr_optional(struct dm_target *ti, unsigned int argc, char **ar > cc->sector_shift = __ffs(cc->sector_size) - SECTOR_SHIFT; > } else if (!strcasecmp(opt_string, "iv_large_sectors")) > set_bit(CRYPT_IV_LARGE_SECTORS, &cc->cipher_flags); > +#ifdef CONFIG_BLK_DEV_INLINE_ENCRYPTION > + else if (!strcasecmp(opt_string, "perform_inline_encrypt")) > + set_bit(DM_CRYPT_INLINE_ENCRYPT, &cc->flags); > +#endif > else { > ti->error = "Invalid feature arguments"; > return -EINVAL; > @@ -2892,6 +2928,13 @@ static int crypt_map(struct dm_target *ti, struct bio *bio) > if (unlikely(bio->bi_iter.bi_size & (cc->sector_size - 1))) > return DM_MAPIO_KILL; > > +#ifdef CONFIG_BLK_DEV_INLINE_ENCRYPTION > + if (cc->key_cfg_idx > 0) { > + crypt_inline_encrypt_submit(cc, ti, bio); > + return DM_MAPIO_SUBMITTED; > + } > +#endif > + > io = dm_per_bio_data(bio, cc->per_bio_data_size); > crypt_io_init(io, cc, bio, dm_target_offset(ti, bio->bi_iter.bi_sector)); > > @@ -2954,6 +2997,10 @@ static void crypt_status(struct dm_target *ti, status_type_t type, > num_feature_args += test_bit(DM_CRYPT_NO_OFFLOAD, &cc->flags); > num_feature_args += cc->sector_size != (1 << SECTOR_SHIFT); > num_feature_args += test_bit(CRYPT_IV_LARGE_SECTORS, &cc->cipher_flags); > +#ifdef CONFIG_BLK_DEV_INLINE_ENCRYPTION > + num_feature_args += > + test_bit(DM_CRYPT_INLINE_ENCRYPT, &cc->flags); > +#endif > if (cc->on_disk_tag_size) > num_feature_args++; > if (num_feature_args) { > @@ -2970,6 +3017,10 @@ static void crypt_status(struct dm_target *ti, status_type_t type, > DMEMIT(" sector_size:%d", cc->sector_size); > if (test_bit(CRYPT_IV_LARGE_SECTORS, &cc->cipher_flags)) > DMEMIT(" iv_large_sectors"); > +#ifdef CONFIG_BLK_DEV_INLINE_ENCRYPTION > + if (test_bit(DM_CRYPT_INLINE_ENCRYPT, &cc->flags)) > + DMEMIT(" perform_inline_encrypt"); > +#endif > } > > break; >