From patchwork Wed Jun 14 23:40:37 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Halcrow X-Patchwork-Id: 9787629 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id B7E4A6038E for ; Wed, 14 Jun 2017 23:40:59 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AC1B626E5D for ; Wed, 14 Jun 2017 23:40:59 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id A0D9727F9F; Wed, 14 Jun 2017 23:40:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C327F26E5D for ; Wed, 14 Jun 2017 23:40:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752812AbdFNXky (ORCPT ); Wed, 14 Jun 2017 19:40:54 -0400 Received: from mail-pg0-f52.google.com ([74.125.83.52]:34586 "EHLO mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752584AbdFNXkx (ORCPT ); Wed, 14 Jun 2017 19:40:53 -0400 Received: by mail-pg0-f52.google.com with SMTP id v18so6744440pgb.1 for ; Wed, 14 Jun 2017 16:40:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references; bh=dH7N5jxN+7V6k2wCBbtEg7MmSqSLODrb2fwDsN6+vFc=; b=IxhSuTnNHrU4I2BaeDQKNobQl9vHo++S4RmRIxdMbIJIpCIQTfSZss+j4PRVpe+VsY l5L+XGSttuoTnbQg4omrU5TUGkPphqXtlCa3KAuwpo4dnAZWyRe4/uy/a9UcVeOc+ngD 1fEJtz0UPzU+32Jx8wPzZrbVQxXwgD3C2jjEQra3hZRYzoGoonNiRtXHJ0kcwNfIk9+y LwkwHqjxN8wDuFL+n7vtAKIdkJtJdqgJhCB0w+w02V6uMYM8aZaAkADLoNbT/6GvAsAv g0QvRioiu1og1Kvyu5lr0p2pywaKSLxWHQTTz55+It26Fm4kK60XCQNEKNRE8HvIGuJc eXqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=dH7N5jxN+7V6k2wCBbtEg7MmSqSLODrb2fwDsN6+vFc=; b=M75qQXd4642xhIBbARzJdevrrXr3z2/2LjuI1JBHEUzm01vQuZ9J3sLhFhd9KqlGSc IiMGSY/GSDEJbs+Zy1LI+Aj1OHsfqD2Tju/3wDepHTl5Ta/M3gnl4E57MSWUj+XGegHD RmrSo4iyOoQUpsM0mc//34p/N+Srqyp1rd20Z7I7UQLOqNHp+jrw6wByZsae1qQzv/ln WCXzwSr3O8Hshyzv9/Hkg+1I321ruCcd9JT1zzDLys8+rH7m9CJTCQypRv/qwWrx/n2F UzriZSIMlNmehWrIeyhTRWVG1VSBaAHxJrZBcCKdNR3t2llJqf5PqSRTVOsNbyNu/vlO IOHQ== X-Gm-Message-State: AKS2vOykt4qk+ql5UBi38iCVzj63E8EbuQqQaS6/4BaBkx4/wZrVrx81 4xpi2i0DVOP8zl5I X-Received: by 10.84.198.35 with SMTP id o32mr2745671pld.194.1497483652264; Wed, 14 Jun 2017 16:40:52 -0700 (PDT) Received: from mhalcrow-linux.kir.corp.google.com ([100.66.175.61]) by smtp.gmail.com with ESMTPSA id z66sm2141286pfl.13.2017.06.14.16.40.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 14 Jun 2017 16:40:50 -0700 (PDT) From: Michael Halcrow To: Michael Halcrow , "Theodore Y . Ts'o" , Eric Biggers , Jaegeuk Kim , linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, dm-devel@redhat.com, linux-ext4@vger.kernel.org, Tyler Hicks Subject: [RFC PATCH 1/4] block: Add bio req flag to disable encryption in block Date: Wed, 14 Jun 2017 16:40:37 -0700 Message-Id: <20170614234040.4326-2-mhalcrow@google.com> X-Mailer: git-send-email 2.13.1.518.g3df882009-goog In-Reply-To: <20170614234040.4326-1-mhalcrow@google.com> References: <20170614234040.4326-1-mhalcrow@google.com> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP When both the file system and a lower layer such as dm-crypt encrypt the same file contents, it impacts performance and power utilization. Depending on how the operating environment manages the encryption keys, there is often no significant security benefit to redundantly encrypting. File systems that encrypt some of their blocks can set the REQ_NOENCRYPT flag as a directive to lower layers to not encrypt. Lower layers may optionally observe the flag, but once thay do, they must continue to observe it on subsequent I/O on the device. Otherwise they will decrypt content that they didn't previously encrypt, resulting in data corruption. Signed-off-by: Michael Halcrow --- include/linux/blk_types.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h index 61339bc44400..89da8f5f7be1 100644 --- a/include/linux/blk_types.h +++ b/include/linux/blk_types.h @@ -205,6 +205,7 @@ enum req_flag_bits { /* command specific flags for REQ_OP_WRITE_ZEROES: */ __REQ_NOUNMAP, /* do not free blocks when zeroing */ + __REQ_NOENCRYPT, /* ok to not encrypt */ __REQ_NR_BITS, /* stops here */ }; @@ -223,6 +224,7 @@ enum req_flag_bits { #define REQ_BACKGROUND (1ULL << __REQ_BACKGROUND) #define REQ_NOUNMAP (1ULL << __REQ_NOUNMAP) +#define REQ_NOENCRYPT (1ULL << __REQ_NOENCRYPT) #define REQ_FAILFAST_MASK \ (REQ_FAILFAST_DEV | REQ_FAILFAST_TRANSPORT | REQ_FAILFAST_DRIVER)