From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=XL0L=G5=lists.01.org=linux-nvdimm-bounces@kernel.org>
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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID,
	DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,
	SPF_PASS,URIBL_BLOCKED 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 2F8B6C433DB
	for <linux-nvdimm@archiver.kernel.org>; Tue, 26 Jan 2021 07:16:21 +0000 (UTC)
Received: from ml01.01.org (ml01.01.org [198.145.21.10])
	(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 A64FF22DFB
	for <linux-nvdimm@archiver.kernel.org>; Tue, 26 Jan 2021 07:16:20 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A64FF22DFB
Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org
Received: from ml01.vlan13.01.org (localhost [IPv6:::1])
	by ml01.01.org (Postfix) with ESMTP id 48353100EBB76;
	Mon, 25 Jan 2021 23:16:20 -0800 (PST)
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=195.135.220.15; helo=mx2.suse.de; envelope-from=mhocko@suse.com; receiver=<UNKNOWN> 
Received: from mx2.suse.de (mx2.suse.de [195.135.220.15])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by ml01.01.org (Postfix) with ESMTPS id 433E4100EBBD0
	for <linux-nvdimm@lists.01.org>; Mon, 25 Jan 2021 23:16:18 -0800 (PST)
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
	t=1611645376; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
	 mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=Rfz4YhgMdQKfWEhdPjTzowRS8ZrfPb0PZUsBEItApiI=;
	b=uSwnbNJryXqrtFn5ZDcik0uto2+MPvheE1cGTKIEOz6ZnfiLtVVNW3xYyy9RGpwnpMhlvH
	1N3K5WJgiIeLyB1+A5OyZuJP2Jkezi6uvJEEzgHe7uQUCBH5hRl4x8iwIwlEA1xmTBtqZQ
	dR3KQIpKfgXY/BC62Y8U0m9xExJlGg8=
Received: from relay2.suse.de (unknown [195.135.221.27])
	by mx2.suse.de (Postfix) with ESMTP id 5743EAE91;
	Tue, 26 Jan 2021 07:16:16 +0000 (UTC)
Date: Tue, 26 Jan 2021 08:16:14 +0100
From: Michal Hocko <mhocko@suse.com>
To: Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH v16 06/11] mm: introduce memfd_secret system call to
 create "secret" memory areas
Message-ID: <20210126071614.GX827@dhcp22.suse.cz>
References: <20210121122723.3446-1-rppt@kernel.org>
 <20210121122723.3446-7-rppt@kernel.org>
 <20210125170122.GU827@dhcp22.suse.cz>
 <20210125213618.GL6332@kernel.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20210125213618.GL6332@kernel.org>
Message-ID-Hash: GWQL2DCYZDAWWJZJYN26KEGAQHDWM5XW
X-Message-ID-Hash: GWQL2DCYZDAWWJZJYN26KEGAQHDWM5XW
X-MailFrom: mhocko@suse.com
X-Mailman-Rule-Hits: nonmember-moderation
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation
CC: Andrew Morton <akpm@linux-foundation.org>, Alexander Viro <viro@zeniv.linux.org.uk>, Andy Lutomirski <luto@kernel.org>, Arnd Bergmann <arnd@arndb.de>, Borislav Petkov <bp@alien8.de>, Catalin Marinas <catalin.marinas@arm.com>, Christopher Lameter <cl@linux.com>, Dave Hansen <dave.hansen@linux.intel.com>, David Hildenbrand <david@redhat.com>, Elena Reshetova <elena.reshetova@intel.com>, "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>, James Bottomley <jejb@linux.ibm.com>, "Kirill A. Shutemov" <kirill@shutemov.name>, Matthew Wilcox <willy@infradead.org>, Mark Rutland <mark.rutland@arm.com>, Mike Rapoport <rppt@linux.ibm.com>, Michael Kerrisk <mtk.manpages@gmail.com>, Palmer Dabbelt <palmer@dabbelt.com>, Paul Walmsley <paul.walmsley@sifive.com>, Peter Zijlstra <peterz@infradead.org>, Rick Edgecombe <rick.p.edgecombe@intel.com>, Roman Gushchin <guro@fb.com>, Shakeel Butt <shakeelb@google.com>, Shuah Khan <shuah@kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Tycho 
 Andersen <tycho@tycho.ws>, Will Deacon <will@kernel.org>, linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org, x86@kernel.org, Hagen Paul Pfeifer <hagen@jauu.net>, Palmer Dabbelt <palmerdabbelt@google.com>
X-Mailman-Version: 3.1.1
Precedence: list
List-Id: "Linux-nvdimm developer list." <linux-nvdimm.lists.01.org>
Archived-At: <https://lists.01.org/hyperkitty/list/linux-nvdimm@lists.01.org/message/GWQL2DCYZDAWWJZJYN26KEGAQHDWM5XW/>
List-Archive: <https://lists.01.org/hyperkitty/list/linux-nvdimm@lists.01.org/>
List-Help: <mailto:linux-nvdimm-request@lists.01.org?subject=help>
List-Post: <mailto:linux-nvdimm@lists.01.org>
List-Subscribe: <mailto:linux-nvdimm-join@lists.01.org>
List-Unsubscribe: <mailto:linux-nvdimm-leave@lists.01.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Mon 25-01-21 23:36:18, Mike Rapoport wrote:
> On Mon, Jan 25, 2021 at 06:01:22PM +0100, Michal Hocko wrote:
> > On Thu 21-01-21 14:27:18, Mike Rapoport wrote:
> > > From: Mike Rapoport <rppt@linux.ibm.com>
> > > 
> > > Introduce "memfd_secret" system call with the ability to create memory
> > > areas visible only in the context of the owning process and not mapped not
> > > only to other processes but in the kernel page tables as well.
> > > 
> > > The user will create a file descriptor using the memfd_secret() system
> > > call. The memory areas created by mmap() calls from this file descriptor
> > > will be unmapped from the kernel direct map and they will be only mapped in
> > > the page table of the owning mm.
> > > 
> > > The secret memory remains accessible in the process context using uaccess
> > > primitives, but it is not accessible using direct/linear map addresses.
> > > 
> > > Functions in the follow_page()/get_user_page() family will refuse to return
> > > a page that belongs to the secret memory area.
> > > 
> > > A page that was a part of the secret memory area is cleared when it is
> > > freed.
> > > 
> > > The following example demonstrates creation of a secret mapping (error
> > > handling is omitted):
> > > 
> > > 	fd = memfd_secret(0);
> > > 	ftruncate(fd, MAP_SIZE);
> > > 	ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
> > 
> > I do not see any access control or permission model for this feature.
> > Is this feature generally safe to anybody?
> 
> The mappings obey memlock limit. Besides, this feature should be enabled
> explicitly at boot with the kernel parameter that says what is the maximal
> memory size secretmem can consume.

Why is such a model sufficient and future proof? I mean even when it has
to be enabled by an admin it is still all or nothing approach. Mlock
limit is not really useful because it is per mm rather than per user.

Is there any reason why this is allowed for non-privileged processes?
Maybe this has been discussed in the past but is there any reason why
this cannot be done by a special device which will allow to provide at
least some permission policy?

Please make sure to describe all those details in the changelog.
-- 
Michal Hocko
SUSE Labs
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@kernel.org>
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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS 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 DD47FC433DB
	for <linux-kernel@archiver.kernel.org>; Tue, 26 Jan 2021 11:13:37 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by mail.kernel.org (Postfix) with ESMTP id A5E7723108
	for <linux-kernel@archiver.kernel.org>; Tue, 26 Jan 2021 11:13:37 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S2388076AbhAZLNS (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Tue, 26 Jan 2021 06:13:18 -0500
Received: from mx2.suse.de ([195.135.220.15]:44972 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1727223AbhAZHRG (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 26 Jan 2021 02:17:06 -0500
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
        t=1611645376; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
         mime-version:mime-version:content-type:content-type:
         in-reply-to:in-reply-to:references:references;
        bh=Rfz4YhgMdQKfWEhdPjTzowRS8ZrfPb0PZUsBEItApiI=;
        b=uSwnbNJryXqrtFn5ZDcik0uto2+MPvheE1cGTKIEOz6ZnfiLtVVNW3xYyy9RGpwnpMhlvH
        1N3K5WJgiIeLyB1+A5OyZuJP2Jkezi6uvJEEzgHe7uQUCBH5hRl4x8iwIwlEA1xmTBtqZQ
        dR3KQIpKfgXY/BC62Y8U0m9xExJlGg8=
Received: from relay2.suse.de (unknown [195.135.221.27])
        by mx2.suse.de (Postfix) with ESMTP id 5743EAE91;
        Tue, 26 Jan 2021 07:16:16 +0000 (UTC)
Date:   Tue, 26 Jan 2021 08:16:14 +0100
From:   Michal Hocko <mhocko@suse.com>
To:     Mike Rapoport <rppt@kernel.org>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Alexander Viro <viro@zeniv.linux.org.uk>,
        Andy Lutomirski <luto@kernel.org>,
        Arnd Bergmann <arnd@arndb.de>, Borislav Petkov <bp@alien8.de>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Christopher Lameter <cl@linux.com>,
        Dan Williams <dan.j.williams@intel.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        David Hildenbrand <david@redhat.com>,
        Elena Reshetova <elena.reshetova@intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
        James Bottomley <jejb@linux.ibm.com>,
        "Kirill A. Shutemov" <kirill@shutemov.name>,
        Matthew Wilcox <willy@infradead.org>,
        Mark Rutland <mark.rutland@arm.com>,
        Mike Rapoport <rppt@linux.ibm.com>,
        Michael Kerrisk <mtk.manpages@gmail.com>,
        Palmer Dabbelt <palmer@dabbelt.com>,
        Paul Walmsley <paul.walmsley@sifive.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        Roman Gushchin <guro@fb.com>,
        Shakeel Butt <shakeelb@google.com>,
        Shuah Khan <shuah@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Tycho Andersen <tycho@tycho.ws>, Will Deacon <will@kernel.org>,
        linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
        linux-nvdimm@lists.01.org, linux-riscv@lists.infradead.org,
        x86@kernel.org, Hagen Paul Pfeifer <hagen@jauu.net>,
        Palmer Dabbelt <palmerdabbelt@google.com>
Subject: Re: [PATCH v16 06/11] mm: introduce memfd_secret system call to
 create "secret" memory areas
Message-ID: <20210126071614.GX827@dhcp22.suse.cz>
References: <20210121122723.3446-1-rppt@kernel.org>
 <20210121122723.3446-7-rppt@kernel.org>
 <20210125170122.GU827@dhcp22.suse.cz>
 <20210125213618.GL6332@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210125213618.GL6332@kernel.org>
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon 25-01-21 23:36:18, Mike Rapoport wrote:
> On Mon, Jan 25, 2021 at 06:01:22PM +0100, Michal Hocko wrote:
> > On Thu 21-01-21 14:27:18, Mike Rapoport wrote:
> > > From: Mike Rapoport <rppt@linux.ibm.com>
> > > 
> > > Introduce "memfd_secret" system call with the ability to create memory
> > > areas visible only in the context of the owning process and not mapped not
> > > only to other processes but in the kernel page tables as well.
> > > 
> > > The user will create a file descriptor using the memfd_secret() system
> > > call. The memory areas created by mmap() calls from this file descriptor
> > > will be unmapped from the kernel direct map and they will be only mapped in
> > > the page table of the owning mm.
> > > 
> > > The secret memory remains accessible in the process context using uaccess
> > > primitives, but it is not accessible using direct/linear map addresses.
> > > 
> > > Functions in the follow_page()/get_user_page() family will refuse to return
> > > a page that belongs to the secret memory area.
> > > 
> > > A page that was a part of the secret memory area is cleared when it is
> > > freed.
> > > 
> > > The following example demonstrates creation of a secret mapping (error
> > > handling is omitted):
> > > 
> > > 	fd = memfd_secret(0);
> > > 	ftruncate(fd, MAP_SIZE);
> > > 	ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
> > 
> > I do not see any access control or permission model for this feature.
> > Is this feature generally safe to anybody?
> 
> The mappings obey memlock limit. Besides, this feature should be enabled
> explicitly at boot with the kernel parameter that says what is the maximal
> memory size secretmem can consume.

Why is such a model sufficient and future proof? I mean even when it has
to be enabled by an admin it is still all or nothing approach. Mlock
limit is not really useful because it is per mm rather than per user.

Is there any reason why this is allowed for non-privileged processes?
Maybe this has been discussed in the past but is there any reason why
this cannot be done by a special device which will allow to provide at
least some permission policy?

Please make sure to describe all those details in the changelog.
-- 
Michal Hocko
SUSE Labs

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=Tegm=G5=lists.infradead.org=linux-riscv-bounces+linux-riscv=archiver.kernel.org@kernel.org>
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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 90891C433E0
	for <linux-riscv@archiver.kernel.org>; Tue, 26 Jan 2021 07:16:50 +0000 (UTC)
Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134])
	(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 1A2A4225AB
	for <linux-riscv@archiver.kernel.org>; Tue, 26 Jan 2021 07:16:49 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1A2A4225AB
Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding:
	Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive:
	List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID:
	Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date:
	Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner;
	 bh=Ccgs9xCYycp8jaj0gSHCvyXc/D5QEQE3A1Ltz5VK76Y=; b=AgbkCacWhW0zidb/JOeMhX8uU
	0PN15IAebmnI65/JuJeEgQgLIEKOe02xaZt/SYWPDpOJSvmi4xMblYEJkpUgZ79CsBOvAxPth0yfx
	3novdCW9vtOTsm2jFE/AaVrFnp0oIGSqtpQAOL5QkZUUgENapdvf1EokQ2MgRMfBV3Vmdwe9RYUHW
	1Iun81HoQ/Null21LZlcaQWAR6y9bm9He03WCvcYOvrDl+MlcFbYp72FAdBvftX44aya/5tlBin/V
	FEYhgCgpr0syNngDPUAZroKSNyF+/l/UNnFIyZ5SOP37bhq+d8ZAHElVB4iMg8ABMLmkFL13IzJqv
	l1F2KorNQ==;
Received: from localhost ([::1] helo=merlin.infradead.org)
	by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux))
	id 1l4IaO-0000ef-9L; Tue, 26 Jan 2021 07:16:24 +0000
Received: from mx2.suse.de ([195.135.220.15])
 by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux))
 id 1l4IaI-0000cv-R6; Tue, 26 Jan 2021 07:16:20 +0000
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
 t=1611645376; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
 mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references;
 bh=Rfz4YhgMdQKfWEhdPjTzowRS8ZrfPb0PZUsBEItApiI=;
 b=uSwnbNJryXqrtFn5ZDcik0uto2+MPvheE1cGTKIEOz6ZnfiLtVVNW3xYyy9RGpwnpMhlvH
 1N3K5WJgiIeLyB1+A5OyZuJP2Jkezi6uvJEEzgHe7uQUCBH5hRl4x8iwIwlEA1xmTBtqZQ
 dR3KQIpKfgXY/BC62Y8U0m9xExJlGg8=
Received: from relay2.suse.de (unknown [195.135.221.27])
 by mx2.suse.de (Postfix) with ESMTP id 5743EAE91;
 Tue, 26 Jan 2021 07:16:16 +0000 (UTC)
Date: Tue, 26 Jan 2021 08:16:14 +0100
From: Michal Hocko <mhocko@suse.com>
To: Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH v16 06/11] mm: introduce memfd_secret system call to
 create "secret" memory areas
Message-ID: <20210126071614.GX827@dhcp22.suse.cz>
References: <20210121122723.3446-1-rppt@kernel.org>
 <20210121122723.3446-7-rppt@kernel.org>
 <20210125170122.GU827@dhcp22.suse.cz>
 <20210125213618.GL6332@kernel.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20210125213618.GL6332@kernel.org>
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 
X-CRM114-CacheID: sfid-20210126_021619_111173_714857C8 
X-CRM114-Status: GOOD (  29.19  )
X-BeenThere: linux-riscv@lists.infradead.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <linux-riscv.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-riscv>,
 <mailto:linux-riscv-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-riscv/>
List-Post: <mailto:linux-riscv@lists.infradead.org>
List-Help: <mailto:linux-riscv-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-riscv>,
 <mailto:linux-riscv-request@lists.infradead.org?subject=subscribe>
Cc: Mark Rutland <mark.rutland@arm.com>, David Hildenbrand <david@redhat.com>,
 Peter Zijlstra <peterz@infradead.org>,
 Catalin Marinas <catalin.marinas@arm.com>,
 Dave Hansen <dave.hansen@linux.intel.com>, linux-mm@kvack.org,
 linux-kselftest@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
 Christopher Lameter <cl@linux.com>, Shuah Khan <shuah@kernel.org>,
 Thomas Gleixner <tglx@linutronix.de>,
 Elena Reshetova <elena.reshetova@intel.com>, linux-arch@vger.kernel.org,
 Tycho Andersen <tycho@tycho.ws>, linux-nvdimm@lists.01.org,
 Will Deacon <will@kernel.org>, x86@kernel.org,
 Matthew Wilcox <willy@infradead.org>, Mike Rapoport <rppt@linux.ibm.com>,
 Ingo Molnar <mingo@redhat.com>, Michael Kerrisk <mtk.manpages@gmail.com>,
 Palmer Dabbelt <palmerdabbelt@google.com>, Arnd Bergmann <arnd@arndb.de>,
 James Bottomley <jejb@linux.ibm.com>, Hagen Paul Pfeifer <hagen@jauu.net>,
 Borislav Petkov <bp@alien8.de>, Alexander Viro <viro@zeniv.linux.org.uk>,
 Andy Lutomirski <luto@kernel.org>, Paul Walmsley <paul.walmsley@sifive.com>,
 "Kirill A. Shutemov" <kirill@shutemov.name>,
 Dan Williams <dan.j.williams@intel.com>, linux-arm-kernel@lists.infradead.org,
 linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
 linux-riscv@lists.infradead.org, Palmer Dabbelt <palmer@dabbelt.com>,
 linux-fsdevel@vger.kernel.org, Shakeel Butt <shakeelb@google.com>,
 Andrew Morton <akpm@linux-foundation.org>,
 Rick Edgecombe <rick.p.edgecombe@intel.com>, Roman Gushchin <guro@fb.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "linux-riscv" <linux-riscv-bounces@lists.infradead.org>
Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org

On Mon 25-01-21 23:36:18, Mike Rapoport wrote:
> On Mon, Jan 25, 2021 at 06:01:22PM +0100, Michal Hocko wrote:
> > On Thu 21-01-21 14:27:18, Mike Rapoport wrote:
> > > From: Mike Rapoport <rppt@linux.ibm.com>
> > > 
> > > Introduce "memfd_secret" system call with the ability to create memory
> > > areas visible only in the context of the owning process and not mapped not
> > > only to other processes but in the kernel page tables as well.
> > > 
> > > The user will create a file descriptor using the memfd_secret() system
> > > call. The memory areas created by mmap() calls from this file descriptor
> > > will be unmapped from the kernel direct map and they will be only mapped in
> > > the page table of the owning mm.
> > > 
> > > The secret memory remains accessible in the process context using uaccess
> > > primitives, but it is not accessible using direct/linear map addresses.
> > > 
> > > Functions in the follow_page()/get_user_page() family will refuse to return
> > > a page that belongs to the secret memory area.
> > > 
> > > A page that was a part of the secret memory area is cleared when it is
> > > freed.
> > > 
> > > The following example demonstrates creation of a secret mapping (error
> > > handling is omitted):
> > > 
> > > 	fd = memfd_secret(0);
> > > 	ftruncate(fd, MAP_SIZE);
> > > 	ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
> > 
> > I do not see any access control or permission model for this feature.
> > Is this feature generally safe to anybody?
> 
> The mappings obey memlock limit. Besides, this feature should be enabled
> explicitly at boot with the kernel parameter that says what is the maximal
> memory size secretmem can consume.

Why is such a model sufficient and future proof? I mean even when it has
to be enabled by an admin it is still all or nothing approach. Mlock
limit is not really useful because it is per mm rather than per user.

Is there any reason why this is allowed for non-privileged processes?
Maybe this has been discussed in the past but is there any reason why
this cannot be done by a special device which will allow to provide at
least some permission policy?

Please make sure to describe all those details in the changelog.
-- 
Michal Hocko
SUSE Labs

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=3d55=G5=lists.infradead.org=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@kernel.org>
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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH,
	DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 1001EC433DB
	for <linux-arm-kernel@archiver.kernel.org>; Tue, 26 Jan 2021 07:18:20 +0000 (UTC)
Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134])
	(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 99E5D22B3F
	for <linux-arm-kernel@archiver.kernel.org>; Tue, 26 Jan 2021 07:18:19 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 99E5D22B3F
Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding:
	Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive:
	List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID:
	Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date:
	Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner;
	 bh=lh0/KYEsX4i8oMWEtdXqFfJ77VP7lqX44J0/DeIiWss=; b=qQs/XCv2p5BBtaJEMoJlWxB2y
	CyXkQQW17YZ7eRMVfit3Xn7RRYA9DsHK2+6JpPLB44cqp9ilFf4BceOAA6dOdKD9zEnJ3LsG19aRV
	ath5jmNR9pmcrCqj/hrtWy6r/o4zK+JJZ/ZHTW9j2Yrcl3QuBysA+Tqd2jJSzMF9wfVvTZ1otb22d
	ns+XD0XIKo1+uDqwAfXr2q6MBXkEPNNAfYT3hZsdptR6Np6cf3yiQqs+JJ6Gp8cNVnvjOH+bAlJIS
	W/RtqqDLJZTXwYTY3kCbSeMERoX8DblF6WVp04s5ftRY+xCDa/JJ0nxJsdV9L58utT8k2zUf+vD1n
	DvbhVknKg==;
Received: from localhost ([::1] helo=merlin.infradead.org)
	by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux))
	id 1l4IaL-0000dk-GR; Tue, 26 Jan 2021 07:16:21 +0000
Received: from mx2.suse.de ([195.135.220.15])
 by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux))
 id 1l4IaI-0000cv-R6; Tue, 26 Jan 2021 07:16:20 +0000
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1;
 t=1611645376; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc:
 mime-version:mime-version:content-type:content-type:
 in-reply-to:in-reply-to:references:references;
 bh=Rfz4YhgMdQKfWEhdPjTzowRS8ZrfPb0PZUsBEItApiI=;
 b=uSwnbNJryXqrtFn5ZDcik0uto2+MPvheE1cGTKIEOz6ZnfiLtVVNW3xYyy9RGpwnpMhlvH
 1N3K5WJgiIeLyB1+A5OyZuJP2Jkezi6uvJEEzgHe7uQUCBH5hRl4x8iwIwlEA1xmTBtqZQ
 dR3KQIpKfgXY/BC62Y8U0m9xExJlGg8=
Received: from relay2.suse.de (unknown [195.135.221.27])
 by mx2.suse.de (Postfix) with ESMTP id 5743EAE91;
 Tue, 26 Jan 2021 07:16:16 +0000 (UTC)
Date: Tue, 26 Jan 2021 08:16:14 +0100
From: Michal Hocko <mhocko@suse.com>
To: Mike Rapoport <rppt@kernel.org>
Subject: Re: [PATCH v16 06/11] mm: introduce memfd_secret system call to
 create "secret" memory areas
Message-ID: <20210126071614.GX827@dhcp22.suse.cz>
References: <20210121122723.3446-1-rppt@kernel.org>
 <20210121122723.3446-7-rppt@kernel.org>
 <20210125170122.GU827@dhcp22.suse.cz>
 <20210125213618.GL6332@kernel.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20210125213618.GL6332@kernel.org>
X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 
X-CRM114-CacheID: sfid-20210126_021619_111173_714857C8 
X-CRM114-Status: GOOD (  29.19  )
X-BeenThere: linux-arm-kernel@lists.infradead.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <linux-arm-kernel.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-arm-kernel>, 
 <mailto:linux-arm-kernel-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-arm-kernel/>
List-Post: <mailto:linux-arm-kernel@lists.infradead.org>
List-Help: <mailto:linux-arm-kernel-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-arm-kernel>, 
 <mailto:linux-arm-kernel-request@lists.infradead.org?subject=subscribe>
Cc: Mark Rutland <mark.rutland@arm.com>, David Hildenbrand <david@redhat.com>,
 Peter Zijlstra <peterz@infradead.org>,
 Catalin Marinas <catalin.marinas@arm.com>,
 Dave Hansen <dave.hansen@linux.intel.com>, linux-mm@kvack.org,
 linux-kselftest@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
 Christopher Lameter <cl@linux.com>, Shuah Khan <shuah@kernel.org>,
 Thomas Gleixner <tglx@linutronix.de>,
 Elena Reshetova <elena.reshetova@intel.com>, linux-arch@vger.kernel.org,
 Tycho Andersen <tycho@tycho.ws>, linux-nvdimm@lists.01.org,
 Will Deacon <will@kernel.org>, x86@kernel.org,
 Matthew Wilcox <willy@infradead.org>, Mike Rapoport <rppt@linux.ibm.com>,
 Ingo Molnar <mingo@redhat.com>, Michael Kerrisk <mtk.manpages@gmail.com>,
 Palmer Dabbelt <palmerdabbelt@google.com>, Arnd Bergmann <arnd@arndb.de>,
 James Bottomley <jejb@linux.ibm.com>, Hagen Paul Pfeifer <hagen@jauu.net>,
 Borislav Petkov <bp@alien8.de>, Alexander Viro <viro@zeniv.linux.org.uk>,
 Andy Lutomirski <luto@kernel.org>, Paul Walmsley <paul.walmsley@sifive.com>,
 "Kirill A. Shutemov" <kirill@shutemov.name>,
 Dan Williams <dan.j.williams@intel.com>, linux-arm-kernel@lists.infradead.org,
 linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
 linux-riscv@lists.infradead.org, Palmer Dabbelt <palmer@dabbelt.com>,
 linux-fsdevel@vger.kernel.org, Shakeel Butt <shakeelb@google.com>,
 Andrew Morton <akpm@linux-foundation.org>,
 Rick Edgecombe <rick.p.edgecombe@intel.com>, Roman Gushchin <guro@fb.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: "linux-arm-kernel" <linux-arm-kernel-bounces@lists.infradead.org>
Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org

On Mon 25-01-21 23:36:18, Mike Rapoport wrote:
> On Mon, Jan 25, 2021 at 06:01:22PM +0100, Michal Hocko wrote:
> > On Thu 21-01-21 14:27:18, Mike Rapoport wrote:
> > > From: Mike Rapoport <rppt@linux.ibm.com>
> > > 
> > > Introduce "memfd_secret" system call with the ability to create memory
> > > areas visible only in the context of the owning process and not mapped not
> > > only to other processes but in the kernel page tables as well.
> > > 
> > > The user will create a file descriptor using the memfd_secret() system
> > > call. The memory areas created by mmap() calls from this file descriptor
> > > will be unmapped from the kernel direct map and they will be only mapped in
> > > the page table of the owning mm.
> > > 
> > > The secret memory remains accessible in the process context using uaccess
> > > primitives, but it is not accessible using direct/linear map addresses.
> > > 
> > > Functions in the follow_page()/get_user_page() family will refuse to return
> > > a page that belongs to the secret memory area.
> > > 
> > > A page that was a part of the secret memory area is cleared when it is
> > > freed.
> > > 
> > > The following example demonstrates creation of a secret mapping (error
> > > handling is omitted):
> > > 
> > > 	fd = memfd_secret(0);
> > > 	ftruncate(fd, MAP_SIZE);
> > > 	ptr = mmap(NULL, MAP_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
> > 
> > I do not see any access control or permission model for this feature.
> > Is this feature generally safe to anybody?
> 
> The mappings obey memlock limit. Besides, this feature should be enabled
> explicitly at boot with the kernel parameter that says what is the maximal
> memory size secretmem can consume.

Why is such a model sufficient and future proof? I mean even when it has
to be enabled by an admin it is still all or nothing approach. Mlock
limit is not really useful because it is per mm rather than per user.

Is there any reason why this is allowed for non-privileged processes?
Maybe this has been discussed in the past but is there any reason why
this cannot be done by a special device which will allow to provide at
least some permission policy?

Please make sure to describe all those details in the changelog.
-- 
Michal Hocko
SUSE Labs

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel