Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1953695ybv; Sat, 8 Feb 2020 09:42:10 -0800 (PST) X-Google-Smtp-Source: APXvYqyecMw54wzTCLxjP9fKUWBiI7GCbQT9UJSnhOdbc/61jVMvDIEViCDsQwsb73oXn3yY9flG X-Received: by 2002:aca:c7cb:: with SMTP id x194mr5917696oif.157.1581183730467; Sat, 08 Feb 2020 09:42:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581183730; cv=none; d=google.com; s=arc-20160816; b=PgeFFZRS46et49qVJFsOJk/JRph0qp2bB85ZRyHofeFimZvgFe12pQKe5aojwSGjxJ 00BmvqLONNMg99FD6tBG8pXzXRvBuOSWozsVFc5ZYLy00mgKuIWykuuUceNaWm80wCND AoO55hUKzQjXPt0qghf1ItiXrQbXEQjiw+Ul7mZqKLY43Hpan+1eTxzFCMcaQZnExx73 CHlCi7dI2ib4aDl+x3YwYLFOGurlpCETz5hJJoq4LjBOxDhfSHst/M+Q+eQ25ER9/6jm Pl8sHCdEr6Ua3aUB32NG5/+Wuj5ONF3anbD93mNke6tyO9OjyBkLoPhwxp5A9nvTGwqh CLcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=vn3SqgJe0Hw9IePrAPjegIrE58hca5dnc5ogakcR4aw=; b=jHsvp9cYUXXCshFUESlx5eH2Xvxd1sNaKxYICgxzNUY2QrgFpxur1mW7yb6zf2lPHm MdVTZ3EeAJ/sWBaW4ZhrOjj6+/xfNgEsCU+L4zmbZAUTYiyEXzCMD/WkU/70UVy6QlPO Z78GKSmNV61UaGd7TN1MM4RONwYaEAh6BDlrMPVSYgtSa28DZchhagT2Xt24gAvG3ZBv 47EmlTLlJetPh4c8haAgBL633di6P6T2wybQO17o10xedeXwPMtqcAd5fRTXDGc/R4KU 1kMiJOWNM2zR79e0CYpKT0BzQabfiRTOE13SNJRy03WcoyYlHWCyaWBNS+W1t16sAdjh Dkxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=1WsJ7Y9D; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a9si5856753oib.59.2020.02.08.09.41.48; Sat, 08 Feb 2020 09:42:10 -0800 (PST) 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; dkim=pass header.i=@kernel.org header.s=default header.b=1WsJ7Y9D; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727471AbgBHRl2 (ORCPT + 99 others); Sat, 8 Feb 2020 12:41:28 -0500 Received: from mail.kernel.org ([198.145.29.99]:43898 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727303AbgBHRl2 (ORCPT ); Sat, 8 Feb 2020 12:41:28 -0500 Received: from hump (unknown [185.189.199.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id ABF6921741; Sat, 8 Feb 2020 17:40:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581183687; bh=M5iGyv9f4kxeousKItvHS+SWTdXy1QHRukV9utRFi0I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=1WsJ7Y9DO7oleGTs2z3bbQ6ik8fmcjNcOtCstN9UfZluoPeE40jiSTGKrjieyy+KV yxp7IlExIl3Lqyi2TpfXtmmHMwPYhOD7Jid6tI5lAdjlhjaHDrZl3fXxWSOiTRv8PV XbTKA7gKNny+Ei/c18DC3J4eljlDYsLLnS28ibDg= Date: Sat, 8 Feb 2020 19:39:22 +0200 From: Mike Rapoport To: Dave Hansen Cc: linux-kernel@vger.kernel.org, Alan Cox , Andrew Morton , Andy Lutomirski , Christopher Lameter , Dave Hansen , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Peter Zijlstra , "Reshetova, Elena" , Thomas Gleixner , Tycho Andersen , linux-api@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC PATCH] mm: extend memfd with ability to create "secret" memory areas Message-ID: <20200208173922.GA15879@hump> References: <20200130162340.GA14232@rapoport-lnx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 06, 2020 at 10:51:13AM -0800, Dave Hansen wrote: > On 1/30/20 8:23 AM, Mike Rapoport wrote: > > include/linux/memfd.h | 9 ++ > > include/uapi/linux/magic.h | 1 + > > include/uapi/linux/memfd.h | 6 + > > mm/Kconfig | 4 + > > mm/Makefile | 1 + > > mm/memfd.c | 10 +- > > mm/secretmem.c | 244 +++++++++++++++++++++++++++++++++++++ > > 7 files changed, 273 insertions(+), 2 deletions(-) > > It seems pretty self-contained and relatively harmless. > > But, how much work is it going to be to tell the rest of the kernel that > page_to_virt() doesn't work any more? Why page_to_virt() won't work anymore? Or you refer to that the kernel code won't be able to access the page contents? > Do we need to make kmap() work on these? I don't think we need to make kmap() work on these. The idea is to prevent kernel from accessing such memory areas. > I guess fixing vm_normal_page() would fix a lot of that. > > In general, my concern about creating little self-contained memory types > is that they will get popular and folks will start wanting more features > from them. For instance, what if I want NUMA affinity, migration, or > large page mappings that are secret? Sure, why not :) Well, this is true for any feature: it may become popular, people will start using it and it will add more complexity. My goal is to design this thing keeping in mind that all the above (and probably more) will be requested sooner or later. > Can these pages work as guest memory? Actually, this is one of the driving usecases. I believe that people that use mem=X to limit kernel control of the memory and the manage the remaining memory for the guests can switch to fd-based approach. > Who would the first users of this thing be? We were thinking about using such areas to store small secrets, e.g. with openssl_malloc(). Another usecase is the VM memory. -- Sincerely yours, Mike.