Received: by 10.213.65.68 with SMTP id h4csp1495721imn; Thu, 29 Mar 2018 05:53:58 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/R37oFjL166gjRUF35XlNE2323/jaRn/46Z5godEhjFfvKt5IhjvP/9Nok9XPa3XXgv1in X-Received: by 2002:a17:902:146:: with SMTP id 64-v6mr8202500plb.30.1522328038315; Thu, 29 Mar 2018 05:53:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522328038; cv=none; d=google.com; s=arc-20160816; b=uWFuvX1M5/ne5ng8l2IK4ftS4kwUrrOtxtRX0LKYNvMxBA7bA8hsJZGq8+5dbpx8Om U6HWrl8BJvxz8my+pN42FCVo9AKh0HQRlW8Dcf9SVqFxEnyKgUQa5xAI++yadTj53Y1C yUvIZW3Ev9sbwzolDQwWTQ9tM6FScileE9mUXTse3JDqtkfLTINGYvKZ1qLzaxG2Gn66 Ak7CZNxZq92bA+zVU1IvscAh1WkZBrJ2Di4GfSEwNDs2o0l8XIsBp6sgJbZUQ0mrT+iM Drl2EgHGwvtKO899+JI5DxNqJH+1WrRcdDnVzhzxkfxDQNuVuGO6udmIoYvQVGVfvZ9L rUGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=iqx61SQ7wgb/vo56SGaleBhHMqrBUoqgta/9InD2jCs=; b=Id0+c/CHvo9W+PR2Yh6fTLckq/l85fKIcat9h51SliaHpafgbW3QC7dFAN/NjmvJFf OESs6H3UC799Qg8fsKWolx5q/ow9Rx2UYhmzJLKXhTfarI4XEmRHVb24u9jYWn2bdP10 krESGReEarnvELxF0AGElS4X8PlbmeQ0icMcS5md0hGjHRPkay2RwxOdeLqc+Ow9U5Es 1aOJpgYXx5+mLVA06uc8e2cMGtFax5K6DTczJ+hokRdvmTt7s0PXytNfkmk++8BF7mFn lV9YnbKBMe1TrUY4dC2rveWPCJQdcUEI2xS1qR+P1BehQM3BgpC9pvNFgc6HQKsbDdIz M05g== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w9si4494190pfk.14.2018.03.29.05.53.44; Thu, 29 Mar 2018 05:53:58 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752497AbeC2Mwc (ORCPT + 99 others); Thu, 29 Mar 2018 08:52:32 -0400 Received: from mx2.suse.de ([195.135.220.15]:40734 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751008AbeC2Mwa (ORCPT ); Thu, 29 Mar 2018 08:52:30 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id F07D7AEF6; Thu, 29 Mar 2018 12:52:28 +0000 (UTC) Date: Thu, 29 Mar 2018 14:52:27 +0200 From: Michal Hocko To: "Kirill A. Shutemov" Cc: "Kirill A. Shutemov" , Ingo Molnar , x86@kernel.org, Thomas Gleixner , "H. Peter Anvin" , Tom Lendacky , Dave Hansen , Kai Huang , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCHv2 06/14] mm/page_alloc: Propagate encryption KeyID through page allocator Message-ID: <20180329125227.GF31039@dhcp22.suse.cz> References: <20180328165540.648-1-kirill.shutemov@linux.intel.com> <20180328165540.648-7-kirill.shutemov@linux.intel.com> <20180329112034.GE31039@dhcp22.suse.cz> <20180329123712.zlo6qmstj3zm5v27@node.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180329123712.zlo6qmstj3zm5v27@node.shutemov.name> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 29-03-18 15:37:12, Kirill A. Shutemov wrote: > On Thu, Mar 29, 2018 at 01:20:34PM +0200, Michal Hocko wrote: > > On Wed 28-03-18 19:55:32, Kirill A. Shutemov wrote: > > > Modify several page allocation routines to pass down encryption KeyID to > > > be used for the allocated page. > > > > > > There are two basic use cases: > > > > > > - alloc_page_vma() use VMA's KeyID to allocate the page. > > > > > > - Page migration and NUMA balancing path use KeyID of original page as > > > KeyID for newly allocated page. > > > > I am sorry but I am out of time to look closer but this just raised my > > eyebrows. This looks like a no-go. The basic allocator has no business > > in fancy stuff like a encryption key. If you need something like that > > then just build a special allocator API on top. This looks like a no-go > > to me. > > The goal is to make memory encryption first class citizen in memory > management and not to invent parallel subsysustem (as we did with hugetlb). How do you get a page_keyid for random kernel allocation? > Making memory encryption integral part of Linux VM would involve handing > encrypted page everywhere we expect anonymous page to appear. How many architectures will implement this feature? -- Michal Hocko SUSE Labs