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=-5.2 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 E2EAAC433E6 for ; Fri, 12 Feb 2021 09:18:44 +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 8BF8D64E30 for ; Fri, 12 Feb 2021 09:18:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8BF8D64E30 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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 5843E100EA2C6; Fri, 12 Feb 2021 01:18:44 -0800 (PST) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=63.128.21.124; helo=us-smtp-delivery-124.mimecast.com; envelope-from=david@redhat.com; receiver= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 40E9C100EA93F for ; Fri, 12 Feb 2021 01:18:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613121519; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=baunC+JA0c74vn12rH+deswOvAmvXs+9aRij2anuo18=; b=MkC/0aY1zksQt9Ga+cXM/PRFIKRMO4EnLeUU3QqKg7GmRmLysHxSNetWiWzHiU8v+hVny4 G26gMeaq0/vudwx33BQ/H0qa4vHxajIBtuzpJkMdtzWfeRKQO46rrA/uRbwSj0wMv4jp97 82KFQFfGEvTBkel+v3qfEpLKV4RDNbo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-380-Led8hCyZOVOQcxBvYOphjw-1; Fri, 12 Feb 2021 04:18:35 -0500 X-MC-Unique: Led8hCyZOVOQcxBvYOphjw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CA327192CC41; Fri, 12 Feb 2021 09:18:29 +0000 (UTC) Received: from [10.36.114.178] (ovpn-114-178.ams2.redhat.com [10.36.114.178]) by smtp.corp.redhat.com (Postfix) with ESMTP id DA5E310023AC; Fri, 12 Feb 2021 09:18:20 +0000 (UTC) To: Mike Rapoport References: <20210208212605.GX242749@kernel.org> <20210209090938.GP299309@linux.ibm.com> <20210211071319.GF242749@kernel.org> <0d66baec-1898-987b-7eaf-68a015c027ff@redhat.com> <20210211112702.GI242749@kernel.org> <05082284-bd85-579f-2b3e-9b1af663eb6f@redhat.com> <20210211230910.GL242749@kernel.org> From: David Hildenbrand Organization: Red Hat GmbH Subject: Re: [PATCH v17 07/10] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: Date: Fri, 12 Feb 2021 10:18:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20210211230910.GL242749@kernel.org> Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Message-ID-Hash: R7QKNMKGG7EG55R53ARZLVM5DLXDBGDP X-Message-ID-Hash: R7QKNMKGG7EG55R53ARZLVM5DLXDBGDP X-MailFrom: david@redhat.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: Michal Hocko , Mike Rapoport , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Anders en , Will Deacon , 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 , Palmer Dabbelt X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii"; format="flowed" Content-Transfer-Encoding: 7bit On 12.02.21 00:09, Mike Rapoport wrote: > On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote: >> On 11.02.21 12:27, Mike Rapoport wrote: >>> On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote: >> >> So let's talk about the main user-visible differences to other memfd files >> (especially, other purely virtual files like hugetlbfs). With secretmem: >> >> - File content can only be read/written via memory mappings. >> - File content cannot be swapped out. >> >> I think there are still valid ways to modify file content using syscalls: >> e.g., fallocate(PUNCH_HOLE). Things like truncate also seems to work just >> fine. > > These work perfectly with any file, so maybe we should have added > memfd_create as a flag to open(2) back then and now the secretmem file > descriptors? I think open() vs memfd_create() makes sense: for open, the path specifies main properties (tmpfs, hugetlbfs, filesystem). On memfd, there is no such path and the "type" has to be specified differently. Also, open() might open existing files - memfd always creates new files. > >>>> AFAIKS, we would need MFD_SECRET and disallow >>>> MFD_ALLOW_SEALING and MFD_HUGETLB. >>> >>> So here we start to multiplex. >> >> Yes. And as Michal said, maybe we can support combinations in the future. > > Isn't there a general agreement that syscall multiplexing is not a good > thing? Looking at mmap(), madvise(), fallocate(), I think multiplexing is just fine and flags can be mutually exclusive - as long as we're not squashing completely unrelated things into a single system call. As one example: we don't have mmap_private() vs. mmap_shared() vs. mmap_shared_validate(). E.g., MAP_SYNC is only available for MAP_SHARED_VALIDATE. > memfd_create already has flags validation that does not look very nice. I assume you're talking about the hugetlb size specifications, right? It's not nice but fairly compact. > Adding there only MFD_SECRET will make it a bit less nice, but when we'll > grow new functionality into secretmem that will become horrible. What do you have in mind? A couple of MFD_SECRET_* flags that only work with MFD_SECRET won't hurt IMHO. Just like we allow MFD_HUGE_* only with MFD_HUGETLB. Thanks, David / dhildenb _______________________________________________ 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: 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=-7.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 6F121C433E0 for ; Fri, 12 Feb 2021 09:20:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 425C764E35 for ; Fri, 12 Feb 2021 09:20:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230034AbhBLJUU (ORCPT ); Fri, 12 Feb 2021 04:20:20 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:23927 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229844AbhBLJUG (ORCPT ); Fri, 12 Feb 2021 04:20:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613121519; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=baunC+JA0c74vn12rH+deswOvAmvXs+9aRij2anuo18=; b=MkC/0aY1zksQt9Ga+cXM/PRFIKRMO4EnLeUU3QqKg7GmRmLysHxSNetWiWzHiU8v+hVny4 G26gMeaq0/vudwx33BQ/H0qa4vHxajIBtuzpJkMdtzWfeRKQO46rrA/uRbwSj0wMv4jp97 82KFQFfGEvTBkel+v3qfEpLKV4RDNbo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-380-Led8hCyZOVOQcxBvYOphjw-1; Fri, 12 Feb 2021 04:18:35 -0500 X-MC-Unique: Led8hCyZOVOQcxBvYOphjw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CA327192CC41; Fri, 12 Feb 2021 09:18:29 +0000 (UTC) Received: from [10.36.114.178] (ovpn-114-178.ams2.redhat.com [10.36.114.178]) by smtp.corp.redhat.com (Postfix) with ESMTP id DA5E310023AC; Fri, 12 Feb 2021 09:18:20 +0000 (UTC) To: Mike Rapoport Cc: Michal Hocko , Mike Rapoport , Andrew Morton , Alexander Viro , Andy Lutomirski , Arnd Bergmann , Borislav Petkov , Catalin Marinas , Christopher Lameter , Dan Williams , Dave Hansen , Elena Reshetova , "H. Peter Anvin" , Ingo Molnar , James Bottomley , "Kirill A. Shutemov" , Matthew Wilcox , Mark Rutland , Michael Kerrisk , Palmer Dabbelt , Paul Walmsley , Peter Zijlstra , Rick Edgecombe , Roman Gushchin , Shakeel Butt , Shuah Khan , Thomas Gleixner , Tycho Andersen , Will Deacon , 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 , Palmer Dabbelt References: <20210208212605.GX242749@kernel.org> <20210209090938.GP299309@linux.ibm.com> <20210211071319.GF242749@kernel.org> <0d66baec-1898-987b-7eaf-68a015c027ff@redhat.com> <20210211112702.GI242749@kernel.org> <05082284-bd85-579f-2b3e-9b1af663eb6f@redhat.com> <20210211230910.GL242749@kernel.org> From: David Hildenbrand Organization: Red Hat GmbH Subject: Re: [PATCH v17 07/10] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: Date: Fri, 12 Feb 2021 10:18:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20210211230910.GL242749@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12.02.21 00:09, Mike Rapoport wrote: > On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote: >> On 11.02.21 12:27, Mike Rapoport wrote: >>> On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote: >> >> So let's talk about the main user-visible differences to other memfd files >> (especially, other purely virtual files like hugetlbfs). With secretmem: >> >> - File content can only be read/written via memory mappings. >> - File content cannot be swapped out. >> >> I think there are still valid ways to modify file content using syscalls: >> e.g., fallocate(PUNCH_HOLE). Things like truncate also seems to work just >> fine. > > These work perfectly with any file, so maybe we should have added > memfd_create as a flag to open(2) back then and now the secretmem file > descriptors? I think open() vs memfd_create() makes sense: for open, the path specifies main properties (tmpfs, hugetlbfs, filesystem). On memfd, there is no such path and the "type" has to be specified differently. Also, open() might open existing files - memfd always creates new files. > >>>> AFAIKS, we would need MFD_SECRET and disallow >>>> MFD_ALLOW_SEALING and MFD_HUGETLB. >>> >>> So here we start to multiplex. >> >> Yes. And as Michal said, maybe we can support combinations in the future. > > Isn't there a general agreement that syscall multiplexing is not a good > thing? Looking at mmap(), madvise(), fallocate(), I think multiplexing is just fine and flags can be mutually exclusive - as long as we're not squashing completely unrelated things into a single system call. As one example: we don't have mmap_private() vs. mmap_shared() vs. mmap_shared_validate(). E.g., MAP_SYNC is only available for MAP_SHARED_VALIDATE. > memfd_create already has flags validation that does not look very nice. I assume you're talking about the hugetlb size specifications, right? It's not nice but fairly compact. > Adding there only MFD_SECRET will make it a bit less nice, but when we'll > grow new functionality into secretmem that will become horrible. What do you have in mind? A couple of MFD_SECRET_* flags that only work with MFD_SECRET won't hurt IMHO. Just like we allow MFD_HUGE_* only with MFD_HUGETLB. Thanks, David / dhildenb 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=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 3CEABC433DB for ; Fri, 12 Feb 2021 09:19:00 +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 023F564DE3 for ; Fri, 12 Feb 2021 09:18:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 023F564DE3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2stmFfKDPjkUzzTp5gp/k5KQDk+OvIje4jE3JRoFfqQ=; b=x0Dx8pvHt+wt3YxRcLWzotjky rI0Jc8YSJ8IBQkthIrYf/VLtKtpPUwFLepSTS2Y0YveBHoHsvv3fJ1W4D1Zc3PiTm9Bq283aYk1pB LOtrzFB8t2U3oOmO3Vgx0+Qt5qVaIgGN++fI1NUw3wVrIx23bnpEdcgAnsxwvSVgyb2QXUupgOSc9 CWedrUiiJO1B/YQOh/HaRQz0Gu6U/SHTkTHXpLsjclvhe6l2G13hsKLpUQyxBL9SDUVX747kkCYwv qxNfUUIA7UUiOiXcRp1oBPIvR1WEIhzeKNmfO11IxjNJXyrkwYMUCzR6Lka5mGoMwA3a1K5dzxUTL xQQCu7UDA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lAUb7-0001Ir-Nq; Fri, 12 Feb 2021 09:18:45 +0000 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lAUb4-0001Gs-8n for linux-riscv@lists.infradead.org; Fri, 12 Feb 2021 09:18:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613121519; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=baunC+JA0c74vn12rH+deswOvAmvXs+9aRij2anuo18=; b=MkC/0aY1zksQt9Ga+cXM/PRFIKRMO4EnLeUU3QqKg7GmRmLysHxSNetWiWzHiU8v+hVny4 G26gMeaq0/vudwx33BQ/H0qa4vHxajIBtuzpJkMdtzWfeRKQO46rrA/uRbwSj0wMv4jp97 82KFQFfGEvTBkel+v3qfEpLKV4RDNbo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-380-Led8hCyZOVOQcxBvYOphjw-1; Fri, 12 Feb 2021 04:18:35 -0500 X-MC-Unique: Led8hCyZOVOQcxBvYOphjw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CA327192CC41; Fri, 12 Feb 2021 09:18:29 +0000 (UTC) Received: from [10.36.114.178] (ovpn-114-178.ams2.redhat.com [10.36.114.178]) by smtp.corp.redhat.com (Postfix) with ESMTP id DA5E310023AC; Fri, 12 Feb 2021 09:18:20 +0000 (UTC) To: Mike Rapoport References: <20210208212605.GX242749@kernel.org> <20210209090938.GP299309@linux.ibm.com> <20210211071319.GF242749@kernel.org> <0d66baec-1898-987b-7eaf-68a015c027ff@redhat.com> <20210211112702.GI242749@kernel.org> <05082284-bd85-579f-2b3e-9b1af663eb6f@redhat.com> <20210211230910.GL242749@kernel.org> From: David Hildenbrand Organization: Red Hat GmbH Subject: Re: [PATCH v17 07/10] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: Date: Fri, 12 Feb 2021 10:18:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20210211230910.GL242749@kernel.org> Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210212_041842_427760_6560818D X-CRM114-Status: GOOD ( 23.25 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Michal Hocko , Peter Zijlstra , Catalin Marinas , Dave Hansen , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, "H. Peter Anvin" , Christopher Lameter , Shuah Khan , Thomas Gleixner , Elena Reshetova , linux-arch@vger.kernel.org, Tycho Andersen , linux-nvdimm@lists.01.org, Will Deacon , x86@kernel.org, Matthew Wilcox , Mike Rapoport , Ingo Molnar , Michael Kerrisk , Palmer Dabbelt , Arnd Bergmann , James Bottomley , Hagen Paul Pfeifer , Borislav Petkov , Alexander Viro , Andy Lutomirski , Paul Walmsley , "Kirill A. Shutemov" , Dan Williams , linux-arm-kernel@lists.infradead.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Palmer Dabbelt , linux-fsdevel@vger.kernel.org, Shakeel Butt , Andrew Morton , Rick Edgecombe , Roman Gushchin Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On 12.02.21 00:09, Mike Rapoport wrote: > On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote: >> On 11.02.21 12:27, Mike Rapoport wrote: >>> On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote: >> >> So let's talk about the main user-visible differences to other memfd files >> (especially, other purely virtual files like hugetlbfs). With secretmem: >> >> - File content can only be read/written via memory mappings. >> - File content cannot be swapped out. >> >> I think there are still valid ways to modify file content using syscalls: >> e.g., fallocate(PUNCH_HOLE). Things like truncate also seems to work just >> fine. > > These work perfectly with any file, so maybe we should have added > memfd_create as a flag to open(2) back then and now the secretmem file > descriptors? I think open() vs memfd_create() makes sense: for open, the path specifies main properties (tmpfs, hugetlbfs, filesystem). On memfd, there is no such path and the "type" has to be specified differently. Also, open() might open existing files - memfd always creates new files. > >>>> AFAIKS, we would need MFD_SECRET and disallow >>>> MFD_ALLOW_SEALING and MFD_HUGETLB. >>> >>> So here we start to multiplex. >> >> Yes. And as Michal said, maybe we can support combinations in the future. > > Isn't there a general agreement that syscall multiplexing is not a good > thing? Looking at mmap(), madvise(), fallocate(), I think multiplexing is just fine and flags can be mutually exclusive - as long as we're not squashing completely unrelated things into a single system call. As one example: we don't have mmap_private() vs. mmap_shared() vs. mmap_shared_validate(). E.g., MAP_SYNC is only available for MAP_SHARED_VALIDATE. > memfd_create already has flags validation that does not look very nice. I assume you're talking about the hugetlb size specifications, right? It's not nice but fairly compact. > Adding there only MFD_SECRET will make it a bit less nice, but when we'll > grow new functionality into secretmem that will become horrible. What do you have in mind? A couple of MFD_SECRET_* flags that only work with MFD_SECRET won't hurt IMHO. Just like we allow MFD_HUGE_* only with MFD_HUGETLB. Thanks, David / dhildenb _______________________________________________ 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: 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.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 2165FC433DB for ; Fri, 12 Feb 2021 09:20:09 +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 C98C964E30 for ; Fri, 12 Feb 2021 09:20:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C98C964E30 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:Subject: From:References:To:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=QATAhS9RoUYFPUPV5yJrG62coybdEPsbv/9evXLKY7I=; b=L4iSYlEaQRav+Rsmmx3lQN13t EBEYhNC5409rqiSSc4j4clTacyGpYCG8oJk7bctIFlah1Q2wpUAdRtfX5gd0hd5my8o5PPdbDMSD9 sqMvwaZkzNEZ9Nki6LQ6TM4UFpS0GoixL6Ln9S5CQRpEbpgI2kUpbd5K/Zt+HlWdu1X10dnRs+9lv w/p1Ua7KZzChaICGPYlJhotEAOT00B67BopfLH8CD99BDhaveDswyVedfkRwiEaf5gB/WJYrU2bab qDGSW/swNFYwQIf1ebZY1CUwEAz0LvikWQxUrrGEVfEamuW4BIlZTOqkAHMtN+K7InN2m2EqfZJEA Rd8i0uoiQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lAUb8-0001JL-Ts; Fri, 12 Feb 2021 09:18:47 +0000 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lAUb4-0001Gt-8B for linux-arm-kernel@lists.infradead.org; Fri, 12 Feb 2021 09:18:43 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613121519; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=baunC+JA0c74vn12rH+deswOvAmvXs+9aRij2anuo18=; b=MkC/0aY1zksQt9Ga+cXM/PRFIKRMO4EnLeUU3QqKg7GmRmLysHxSNetWiWzHiU8v+hVny4 G26gMeaq0/vudwx33BQ/H0qa4vHxajIBtuzpJkMdtzWfeRKQO46rrA/uRbwSj0wMv4jp97 82KFQFfGEvTBkel+v3qfEpLKV4RDNbo= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-380-Led8hCyZOVOQcxBvYOphjw-1; Fri, 12 Feb 2021 04:18:35 -0500 X-MC-Unique: Led8hCyZOVOQcxBvYOphjw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CA327192CC41; Fri, 12 Feb 2021 09:18:29 +0000 (UTC) Received: from [10.36.114.178] (ovpn-114-178.ams2.redhat.com [10.36.114.178]) by smtp.corp.redhat.com (Postfix) with ESMTP id DA5E310023AC; Fri, 12 Feb 2021 09:18:20 +0000 (UTC) To: Mike Rapoport References: <20210208212605.GX242749@kernel.org> <20210209090938.GP299309@linux.ibm.com> <20210211071319.GF242749@kernel.org> <0d66baec-1898-987b-7eaf-68a015c027ff@redhat.com> <20210211112702.GI242749@kernel.org> <05082284-bd85-579f-2b3e-9b1af663eb6f@redhat.com> <20210211230910.GL242749@kernel.org> From: David Hildenbrand Organization: Red Hat GmbH Subject: Re: [PATCH v17 07/10] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: Date: Fri, 12 Feb 2021 10:18:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <20210211230910.GL242749@kernel.org> Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210212_041842_422159_6379B19F X-CRM114-Status: GOOD ( 24.24 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Michal Hocko , Peter Zijlstra , Catalin Marinas , Dave Hansen , linux-mm@kvack.org, linux-kselftest@vger.kernel.org, "H. Peter Anvin" , Christopher Lameter , Shuah Khan , Thomas Gleixner , Elena Reshetova , linux-arch@vger.kernel.org, Tycho Andersen , linux-nvdimm@lists.01.org, Will Deacon , x86@kernel.org, Matthew Wilcox , Mike Rapoport , Ingo Molnar , Michael Kerrisk , Palmer Dabbelt , Arnd Bergmann , James Bottomley , Hagen Paul Pfeifer , Borislav Petkov , Alexander Viro , Andy Lutomirski , Paul Walmsley , "Kirill A. Shutemov" , Dan Williams , linux-arm-kernel@lists.infradead.org, linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Palmer Dabbelt , linux-fsdevel@vger.kernel.org, Shakeel Butt , Andrew Morton , Rick Edgecombe , Roman Gushchin Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 12.02.21 00:09, Mike Rapoport wrote: > On Thu, Feb 11, 2021 at 01:07:10PM +0100, David Hildenbrand wrote: >> On 11.02.21 12:27, Mike Rapoport wrote: >>> On Thu, Feb 11, 2021 at 10:01:32AM +0100, David Hildenbrand wrote: >> >> So let's talk about the main user-visible differences to other memfd files >> (especially, other purely virtual files like hugetlbfs). With secretmem: >> >> - File content can only be read/written via memory mappings. >> - File content cannot be swapped out. >> >> I think there are still valid ways to modify file content using syscalls: >> e.g., fallocate(PUNCH_HOLE). Things like truncate also seems to work just >> fine. > > These work perfectly with any file, so maybe we should have added > memfd_create as a flag to open(2) back then and now the secretmem file > descriptors? I think open() vs memfd_create() makes sense: for open, the path specifies main properties (tmpfs, hugetlbfs, filesystem). On memfd, there is no such path and the "type" has to be specified differently. Also, open() might open existing files - memfd always creates new files. > >>>> AFAIKS, we would need MFD_SECRET and disallow >>>> MFD_ALLOW_SEALING and MFD_HUGETLB. >>> >>> So here we start to multiplex. >> >> Yes. And as Michal said, maybe we can support combinations in the future. > > Isn't there a general agreement that syscall multiplexing is not a good > thing? Looking at mmap(), madvise(), fallocate(), I think multiplexing is just fine and flags can be mutually exclusive - as long as we're not squashing completely unrelated things into a single system call. As one example: we don't have mmap_private() vs. mmap_shared() vs. mmap_shared_validate(). E.g., MAP_SYNC is only available for MAP_SHARED_VALIDATE. > memfd_create already has flags validation that does not look very nice. I assume you're talking about the hugetlb size specifications, right? It's not nice but fairly compact. > Adding there only MFD_SECRET will make it a bit less nice, but when we'll > grow new functionality into secretmem that will become horrible. What do you have in mind? A couple of MFD_SECRET_* flags that only work with MFD_SECRET won't hurt IMHO. Just like we allow MFD_HUGE_* only with MFD_HUGETLB. Thanks, David / dhildenb _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel