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=-4.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 D014CC433DB for ; Thu, 11 Feb 2021 11:21:54 +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 7425664E26 for ; Thu, 11 Feb 2021 11:21:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7425664E26 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=EbAv0r3IOkj0jyVLmhyNn7gX1cJ0M1qAwj+yuGrt0Jc=; b=Z62zYfF3AGVY69Dfv0fKLVJRc vl+MrJOwGvuhrQFUzFaJv1akZ4V+PGW3dYFH6z78GimIoolW16wGUzBKoShzDtxXlivqJpOpJCF92 s5vqs7ilyorVVHnhWqgaRonkYCAoVyf7ye0Zm85d6uDW+P/rB2QbtWipM20QWDHSYSRlVuvgvcM8P hyu5yGi/5zBuz146xYqXXfuIG/sm2UMVcE6S+aAmxwK0XZdeJqBvDLmr0NHyF0JehudbwxUrRycIE 60NPBN5ArFOSGsk/RrNGf5Ev240ukSb8K51B/9h6nPmHJcExv4qWtFjdi7ad5vfiAajcYBKp5ndxk LTb3bf6FA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lAA1S-0005UU-90; Thu, 11 Feb 2021 11:20:34 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lAA1O-0005Sj-9G; Thu, 11 Feb 2021 11:20:31 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 14FAC64DCF; Thu, 11 Feb 2021 11:20:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613042428; bh=rXRK0H6A/K2Wb0tbxmc7ZILxeVB76yptr2cmsMFQE74=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t3VWHvs0bXUxcCXOc97N7vSXyLqVUcEV92kaL6OdVxecAKxAQ7ns6LLG+vegpOVde U9dBh6sezDjn5D92Ll5noX1Vr+yCYEIk5R0rIUlhKrjSS7aOZ0i+PaR/+DQIweUHh6 8FzOzWyaxJsUOVv2GFc6tXB0iA4Kh3UCZBlISlSmmeVmiew2dh6clqSD3WkV3s59X7 15MQmJD2s7JLI/6iNb4Cojk2vx4RU0Y7gohP8KiCudLNjAvDZFFfG0p33iCbt4dNcP wEYFcHPp1StbE/lV4MGjTaz8WVMajl7z6z/1pA+KZbglGlxEBvUgFNkTEZP1OvrqS8 dLaGA+Ls37rug== Date: Thu, 11 Feb 2021 13:20:08 +0200 From: Mike Rapoport To: Michal Hocko Subject: Re: [PATCH v17 07/10] mm: introduce memfd_secret system call to create "secret" memory areas Message-ID: <20210211112008.GH242749@kernel.org> References: <20210208084920.2884-1-rppt@kernel.org> <20210208084920.2884-8-rppt@kernel.org> <20210208212605.GX242749@kernel.org> <20210209090938.GP299309@linux.ibm.com> <20210211071319.GF242749@kernel.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210211_062030_605766_898853B4 X-CRM114-Status: GOOD ( 35.27 ) 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 , David Hildenbrand , 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Feb 11, 2021 at 09:39:38AM +0100, Michal Hocko wrote: > On Thu 11-02-21 09:13:19, Mike Rapoport wrote: > > On Tue, Feb 09, 2021 at 02:17:11PM +0100, Michal Hocko wrote: > > > On Tue 09-02-21 11:09:38, Mike Rapoport wrote: > [...] > > > > Citing my older email: > > > > > > > > I've hesitated whether to continue to use new flags to memfd_create() or to > > > > add a new system call and I've decided to use a new system call after I've > > > > started to look into man pages update. There would have been two completely > > > > independent descriptions and I think it would have been very confusing. > > > > > > Could you elaborate? Unmapping from the kernel address space can work > > > both for sealed or hugetlb memfds, no? Those features are completely > > > orthogonal AFAICS. With a dedicated syscall you will need to introduce > > > this functionality on top if that is required. Have you considered that? > > > I mean hugetlb pages are used to back guest memory very often. Is this > > > something that will be a secret memory usecase? > > > > > > Please be really specific when giving arguments to back a new syscall > > > decision. > > > > Isn't "syscalls have completely independent description" specific enough? > > No, it's not as you can see from questions I've had above. More on that > below. > > > We are talking about API here, not the implementation details whether > > secretmem supports large pages or not. > > > > The purpose of memfd_create() is to create a file-like access to memory. > > The purpose of memfd_secret() is to create a way to access memory hidden > > from the kernel. > > > > I don't think overloading memfd_create() with the secretmem flags because > > they happen to return a file descriptor will be better for users, but > > rather will be more confusing. > > This is quite a subjective conclusion. I could very well argue that it > would be much better to have a single syscall to get a fd backed memory > with spedific requirements (sealing, unmapping from the kernel address > space). > Neither of us would be clearly right or wrong. 100% agree :) > A more important point is a future extensibility and usability, though. > So let's just think of few usecases I have outlined above. Is it > unrealistic to expect that secret memory should be sealable? What about > hugetlb? Because if the answer is no then a new API is a clear win as the > combination of flags would never work and then we would just suffer from > the syscall multiplexing without much gain. On the other hand if > combination of the functionality is to be expected then you will have to > jam it into memfd_create and copy the interface likely causing more > confusion. See what I mean? I see your point, but I think that overloading memfd_create definitely gets us into syscall multiplexing from day one and support for seals and huge pages in the secretmem will not make it less of a multiplexer. Sealing is anyway controlled via fcntl() and I don't think MFD_ALLOW_SEALING makes much sense for the secretmem because it is there to prevent rogue file sealing in tmpfs/hugetlbfs. As for the huge pages, I'm not sure at all that supporting huge pages in secretmem will involve hugetlbfs. And even if yes, adding SECRETMEM_HUGE flag seems to me less confusing than saying "from kernel x.y you can use MFD_CREATE | MFD_SECRET | MFD_HUGE" etc for all possible combinations. > I by no means do not insist one way or the other but from what I have > seen so far I have a feeling that the interface hasn't been thought > through enough. It has been, but we have different thoughts about it ;-) -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel