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=-1.0 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED autolearn=ham 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 090B8C4151A for ; Wed, 13 Feb 2019 00:27:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id BF288222BE for ; Wed, 13 Feb 2019 00:27:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="A75fEOe9" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732249AbfBMA1d (ORCPT ); Tue, 12 Feb 2019 19:27:33 -0500 Received: from mail-ot1-f66.google.com ([209.85.210.66]:38105 "EHLO mail-ot1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727343AbfBMA1d (ORCPT ); Tue, 12 Feb 2019 19:27:33 -0500 Received: by mail-ot1-f66.google.com with SMTP id m1so1056040otf.5 for ; Tue, 12 Feb 2019 16:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=y2TCsZERRG+6EYzxN92qIb/n/TWRZq+et/eHaEh69F0=; b=A75fEOe9R90kV2GScPTNMAUPngiL+eNMY0oZ0OKHPk5OztxH9Df7c6sM0DuZCgI60/ 5Mb1cu6iCxdd6riY0ClnsLL3/8Ym8StuKIcf46LFb3QUwVgL4LdKmvTtoQUq7aD6++wq TPgiQ6QMgWwm+T+DuD36275BXXGaVy/HcxsRpaG87l54O4IbIAjgxb2GSF0T6onLjw5P WrneLaFVMEke/K5DgHV+Hjylb4RGHX+lu4mahDLCGqJJxlOR6xjuMezGYPMrdHgmLgtz imyROKKwGwMBrK3e5BDamtqLCRgAkiqzBcqmfdsHTJtoh+Y/Cqyyk6nQf0kzwZGl2fqi IJYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=y2TCsZERRG+6EYzxN92qIb/n/TWRZq+et/eHaEh69F0=; b=sNTfaBj2A02kNz2OBw1+86AKoyfAN4OZb62Af6luR/Por3AQEKjd2xHJ16cNnBFj7o zQaymUWGU35AnVAVyOt1JYNp2iqFysF+gFIUpMPOPrde9O8r9QlE3V8cggDoUSM37OJp gUwj6TPVrqtgaCIB6xW7e9DzkcR3E7gzuQjbZmEU/C1oX1ljTtDMR4/1wPuDlP4GDfF9 31gwb8AeTuGWpxnidwCYZwo/qCl40lsY9KAqw4gA75a2LndYhFf3Wg/itXFoLOtWPUud jQR1fHQJIem04+m65p3rRNwbYyabYdlt8DEvJ6MR6yQq4WZLHOe/+8K440YbbTrhxZSL iamw== X-Gm-Message-State: AHQUAubwxr8IblnNfVlIs/Fr4q1VYf4H3FvBc8BaSlpJiH3p3ypVk+dT QAATPZU99fl8mLkxX2HDaSqeDdPe4FbYiHoTXqzVmg== X-Google-Smtp-Source: AHgI3IbnvF7P5f16Hzx1P+INe5f+ZZu/+RzqOFetn+03YPaE7a/8n1/bJKYqMcDXqTJojYjxvyFnq/ZoJZouHT3V88c= X-Received: by 2002:a9d:37b7:: with SMTP id x52mr6870269otb.214.1550017652285; Tue, 12 Feb 2019 16:27:32 -0800 (PST) MIME-Version: 1.0 References: <788d7050-f6bb-b984-69d9-504056e6c5a6@intel.com> <20190212235114.GM20493@dastard> In-Reply-To: <20190212235114.GM20493@dastard> From: Dan Williams Date: Tue, 12 Feb 2019 16:27:20 -0800 Message-ID: Subject: Re: [LSF/MM TOPIC] Memory Encryption on top of filesystems To: Dave Chinner Cc: Dave Hansen , lsf-pc@lists.linux-foundation.org, linux-fsdevel , Linux-MM , "Shutemov, Kirill" , "Schofield, Alison" , "Darrick J. Wong" , Jan Kara , Christoph Hellwig Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue, Feb 12, 2019 at 3:51 PM Dave Chinner wrote: > > On Tue, Feb 12, 2019 at 08:55:57AM -0800, Dave Hansen wrote: > > Multi-Key Total Memory Encryption (MKTME) [1] is feature of a memory > > controller that allows memory to be selectively encrypted with > > user-controlled key, in hardware, at a very low runtime cost. However, > > it is implemented using AES-XTS which encrypts each block with a key > > that is generated based on the physical address of the data being > > encrypted. This has nice security properties, making some replay and > > substitution attacks harder, but it means that encrypted data can not b= e > > naively relocated. > > The subject is "Memory Encryption on top of filesystems", but really > what you are talking about is "physical memory encryption /below/ > filesystems". > > i.e. it's encryption of the physical storage the filesystem manages, > not encryption within the fileystem (like fscrypt) or or user data > on top of the filesystem (ecryptfs or userspace). > > > Combined with persistent memory, MKTME allows data to be unlocked at th= e > > device (DIMM or namespace) level, but left encrypted until it actually > > needs to be used. > > This sounds more like full disk encryption (either in the IO > path software by dm-crypt or in hardware itself), where the contents > are decrypted/encrypted in the IO path as the data is moved between > physical storage and the filesystem's memory (page/buffer caches). > > Is there any finer granularity than a DIMM or pmem namespace for > specifying encrypted regions? Note that filesystems are not aware of > the physical layout of the memory address space (i.e. what DIMM > corresponds to which sector in the block device), so DIMM-level > granularity doesn't seem particularly useful right now.... > > Also, how many different hardware encryption keys are available for > use, and how many separate memory regions can a single key have > associated with it? > > > However, if encrypted data were placed on a > > filesystem, it might be in its encrypted state for long periods of time > > and could not be moved by the filesystem during that time. > > I'm not sure what you mean by "if encrypted data were placed on a > filesystem", given that the memory encryption is transparent to the > filesystem (i.e. happens in the memory controller on it's way > to/from the physical storage). > > > The =E2=80=9Ceasy=E2=80=9D solution to this is to just require that the= encryption key > > be present and programmed into the memory controller before data is > > moved. However, this means that filesystems would need to know when a > > given block has been encrypted and can not be moved. > > I'm missing something here - how does the filesystem even get > mounted if we haven't unlocked the device the filesystem is stored > on? i.e. we need to unlock the entire memory region containing the > filesystem so it can read and write it's metadata (which can be > randomly spread all over the block device). > > And if we have to do that to mount the filesystem, then aren't we > also unlocking all the same memory regions that contain user data > and hence they can be moved? Yes, and this is the most likely scenario for enabling MKTME with persistent memory. The filesystem will not be able to mount until the entire physical address range (namespace device) is unlocked, and the filesystem is kept unaware of the encryption. One key per namespace device. > At what point do we end up with a filesystem mounted and trying to > access a locked memory region? Another option is to enable encryption to be specified at mmap time with the motivation of being able to use the file system for provisioning instead of managing multiple namespaces. The filesystem would need to be careful to use the key for any physical block management, and a decision would need to be made about when/whether read(2)/write(2) access cipher text . The current thinking is that this would be too invasive / restrictive for the filesystem, but it's otherwise an interesting thought experiment for allowing the filesystem to take on more physical-storage allocation responsibilities.