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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 285A2C31E5B for ; Tue, 18 Jun 2019 01:35:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 02F9C20679 for ; Tue, 18 Jun 2019 01:35:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727000AbfFRBfv (ORCPT ); Mon, 17 Jun 2019 21:35:51 -0400 Received: from mga14.intel.com ([192.55.52.115]:44033 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725829AbfFRBfv (ORCPT ); Mon, 17 Jun 2019 21:35:51 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Jun 2019 18:35:50 -0700 X-ExtLoop1: 1 Received: from khuang2-desk.gar.corp.intel.com ([10.255.91.82]) by fmsmga004.fm.intel.com with ESMTP; 17 Jun 2019 18:35:47 -0700 Message-ID: <1560821746.5187.82.camel@linux.intel.com> Subject: Re: [PATCH, RFC 45/62] mm: Add the encrypt_mprotect() system call for MKTME From: Kai Huang To: Andy Lutomirski Cc: Dave Hansen , "Kirill A. Shutemov" , Andrew Morton , X86 ML , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Borislav Petkov , Peter Zijlstra , David Howells , Kees Cook , Jacob Pan , Alison Schofield , Linux-MM , kvm list , keyrings@vger.kernel.org, LKML , Tom Lendacky Date: Tue, 18 Jun 2019 13:35:46 +1200 In-Reply-To: References: <20190508144422.13171-1-kirill.shutemov@linux.intel.com> <20190508144422.13171-46-kirill.shutemov@linux.intel.com> <3c658cce-7b7e-7d45-59a0-e17dae986713@intel.com> <5cbfa2da-ba2e-ed91-d0e8-add67753fc12@intel.com> <1560816342.5187.63.camel@linux.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > > > > > I'm having a hard time imagining that ever working -- wouldn't it blow > > > up if someone did: > > > > > > fd = open("/dev/anything987"); > > > ptr1 = mmap(fd); > > > ptr2 = mmap(fd); > > > sys_encrypt(ptr1); > > > > > > So I think it really has to be: > > > fd = open("/dev/anything987"); > > > ioctl(fd, ENCRYPT_ME); > > > mmap(fd); > > > > This requires "/dev/anything987" to support ENCRYPT_ME ioctl, right? > > > > So to support NVDIMM (DAX), we need to add ENCRYPT_ME ioctl to DAX? > > Yes and yes, or we do it with layers -- see below. > > I don't see how we can credibly avoid this. If we try to do MKTME > behind the DAX driver's back, aren't we going to end up with cache > coherence problems? I am not sure whether I understand correctly but how is cache coherence problem related to putting MKTME concept to different layers? To make MKTME work with DAX/NVDIMM, I think no matter which layer MKTME concept resides, eventually we need to put keyID into PTE which maps to NVDIMM, and kernel needs to manage cache coherence for NVDIMM just like for normal memory showed in this series? Thanks, -Kai