From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ECDD3CA9EB6 for ; Wed, 23 Oct 2019 12:57:33 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id AF58520640; Wed, 23 Oct 2019 12:57:33 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="Riy4e/zn"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="B3KS/hs0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AF58520640 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mit.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-2.v29.lw.sourceforge.com) by sfs-ml-2.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1iNGCi-00054J-Oc; Wed, 23 Oct 2019 12:57:32 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1iNGCh-00054C-G4 for linux-f2fs-devel@lists.sourceforge.net; Wed, 23 Oct 2019 12:57:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=In-Reply-To:Content-Type:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=l2cQJDoUTRUcJk4WJHtfIvuEu/pcOoRpz7qkEPnP9rM=; b=Riy4e/znNSsuZXISHM0cb7qF2C gzJYnFpd4RumH7VOHI5BiDQRqwSbVCJ3huLV1dLtpQ28gFe1x3pa9oJ44WdQyLkUPU18ds9rKX6z0 vSlh6Cw0pw0pIWHWu28K8k6RTcHS58MOYK8hiLyrB/hiT4du30N2iOCtHO7viPam1PIk=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To :From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=l2cQJDoUTRUcJk4WJHtfIvuEu/pcOoRpz7qkEPnP9rM=; b=B3KS/hs0BPDVVoifLtbZ3GbS0q pMaC4897oJv1XqVCPHuzJkjCYsvIa0YooYiJGXJrHO4PLXY7KL9TGT19fgpkjtWB/p83pxELGL8eX L9Evp7qhRfZIeBlwsM5YxdZ8AkPWlbJZoNFiZYa6q2d7kZGwD8qbXyM7ScCHfvbP/qvo=; Received: from outgoing-auth-1.mit.edu ([18.9.28.11] helo=outgoing.mit.edu) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1iNGCf-000JHl-Hs for linux-f2fs-devel@lists.sourceforge.net; Wed, 23 Oct 2019 12:57:31 +0000 Received: from callcc.thunk.org (guestnat-104-133-0-98.corp.google.com [104.133.0.98] (may be forged)) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x9NCv1VA016128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Oct 2019 08:57:02 -0400 Received: by callcc.thunk.org (Postfix, from userid 15806) id 3FF4B420456; Wed, 23 Oct 2019 08:57:01 -0400 (EDT) Date: Wed, 23 Oct 2019 08:57:01 -0400 From: "Theodore Y. Ts'o" To: Christoph Hellwig Message-ID: <20191023125701.GA2460@mit.edu> References: <20191021230355.23136-1-ebiggers@kernel.org> <20191021230355.23136-2-ebiggers@kernel.org> <20191022052712.GA2083@dread.disaster.area> <20191022060004.GA333751@sol.localdomain> <20191022133001.GA23268@mit.edu> <20191023092718.GA23274@infradead.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20191023092718.GA23274@infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Headers-End: 1iNGCf-000JHl-Hs Subject: Re: [f2fs-dev] [PATCH 1/3] fscrypt: add support for inline-encryption-optimized policies X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-f2fs-devel@lists.sourceforge.net, Dave Chinner , Satya Tangirala , Paul Lawrence , linux-fscrypt@vger.kernel.org, linux-fsdevel@vger.kernel.org, Jaegeuk Kim , linux-ext4@vger.kernel.org, Paul Crowley Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On Wed, Oct 23, 2019 at 02:27:18AM -0700, Christoph Hellwig wrote: > On Tue, Oct 22, 2019 at 09:30:01AM -0400, Theodore Y. Ts'o wrote: > > If and when we actually get inline crypto support for server-class > > systems, hopefully they will support 128-bit DUN's, and/or they will > > have sufficiently fast key load times such that we can use per-file > > keying. > > NVMe is working on a key per I/O feature. So at very least the naming > of this option should be "crappy_underwhelming_embedded_inline_crypto" If and when the vaporware shows up in real hardware, and assuming that fscrypt is useful for this hardware, we can name it "super_duper_fancy_inline_crypto". :-) Remember that fscrypt only encrypts the data and the file name. It doesn't encrypt the metadata. It has very specific use cases for Android and ChromeOS where you have multiple users that need to use different keys, and in the case of ChromeOS, we want to be able to efficiently use the space so that while user A is logged in, we can delete files in user B's cache directory without user B's keys being present. (This is why we can't use fixed per-user partitions with dm-crypt; that solution was considered and rejected before we started work on fscrypt.) If you aren't working under tight space and cost constraints, it's actually better to encrypt the whole partition, so that all of the metadata can be protected. fscrypt is deployed in millions and millions of devices, and is solving real world problems. However, it never claimed to be the only way to address encryption in the storage stack --- and it's not at all clear fscrypt is the way that makes the most amount of sense for NVMe devices. So let's cross that bridge when we get to it. Cheers, - Ted _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel