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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6E05DC433FE for ; Mon, 17 Oct 2022 19:05:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CEB186B0074; Mon, 17 Oct 2022 15:05:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C741A6B0075; Mon, 17 Oct 2022 15:05:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AEF256B0078; Mon, 17 Oct 2022 15:05:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 9CF856B0074 for ; Mon, 17 Oct 2022 15:05:49 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 687961C6659 for ; Mon, 17 Oct 2022 19:05:49 +0000 (UTC) X-FDA: 80031370818.20.D3572C8 Received: from mail-lj1-f176.google.com (mail-lj1-f176.google.com [209.85.208.176]) by imf20.hostedemail.com (Postfix) with ESMTP id 03C091C0036 for ; Mon, 17 Oct 2022 19:05:48 +0000 (UTC) Received: by mail-lj1-f176.google.com with SMTP id b18so15119533ljr.13 for ; Mon, 17 Oct 2022 12:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tpLbF7MUjfgdwKeolFrKwUGGJvkFHEynVfhNRIRYzO0=; b=cTXJI0UBOdBxXG2IHW1rqIDOvBkglMHN1TS3v9u/Mg6E19sNCf3CHq90Ltlb8bjRuV uwZxsI3QP9DlzIDrz8Ff7f9zknZmBhB2m3pkIj381yHasQYOvkpoqdJncN9JKC2twFC8 ShVufGPOkpE2dB+4eCyihCzXtxWBY+X/y95BOpw7uAHWW2nmY6ScgSdvp0Pxz6khfbyi YxhW1XKkSTezSkUawIx5/j0VpvJshXk6TJGUrtcsbKTwNFF6pKmyHcosQZh7T9atBa+E fdb7oqoR8tN6oS+MAKpeLCi//GJfCoW515YxPGh6OzLSq2gny6eetjefpyJ4o3QbBEiq 9V6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tpLbF7MUjfgdwKeolFrKwUGGJvkFHEynVfhNRIRYzO0=; b=lW4lmUWREzUfKcvaHMpp9OCkmAQNYwrC8yorIalzD9uwPPAPqreyoWHddSbApdgyvf ST0HriJqjN1rgyYzvGF+iRFkSDYDQ1OmUPZlNBb5dGn6XbmsNWO+YAu/ejjhZ1+mTSjf RT0ynblVxF19rvrt18bOYgqDjXUVhQEwbfWzaZc1RgRr704VPzDkOT2BXobSfMlVRsyd rz/lSOkp82tsbJ2yY0aVG4FbiQzfHlbPjHIYkdKABgj0XAbUbzt0EDTYF52MmhyB0bCh AtabAndrnMXPK9BVfrRtpiof7L0cIgLZMe4pVz1HO9On5CQaHoxEo/oVJ2YC5187bOch lUBQ== X-Gm-Message-State: ACrzQf1yeJvMoWYnXnGtozsbWkwOdalXcqiWojZbjBMmeTAUBFa0JveI 2JPvIGAUhT+2q+8g6lUBhDqycSReRo4A+Znbxt/Icw== X-Google-Smtp-Source: AMsMyM4AkQi9c7U3RtdWYwjcZCizC5KFrocAewLyWt0H2WuNks4/hroyUpSgGTZ2Szy1PxqSxcVc8+OpiywAfS+j4K8= X-Received: by 2002:a05:651c:20d:b0:26f:bc4c:f957 with SMTP id y13-20020a05651c020d00b0026fbc4cf957mr4763341ljn.199.1666033547017; Mon, 17 Oct 2022 12:05:47 -0700 (PDT) MIME-Version: 1.0 References: <20220915142913.2213336-2-chao.p.peng@linux.intel.com> <20220926142330.GC2658254@chaop.bj.intel.com> <20221013133457.GA3263142@chaop.bj.intel.com> <20221017145856.GB3417432@chaop.bj.intel.com> In-Reply-To: <20221017145856.GB3417432@chaop.bj.intel.com> From: Fuad Tabba Date: Mon, 17 Oct 2022 20:05:10 +0100 Message-ID: Subject: Re: [PATCH v8 1/8] mm/memfd: Introduce userspace inaccessible memfd To: Chao Peng Cc: Sean Christopherson , David Hildenbrand , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, qemu-devel@nongnu.org, Paolo Bonzini , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H . Peter Anvin" , Hugh Dickins , Jeff Layton , "J . Bruce Fields" , Andrew Morton , Shuah Khan , Mike Rapoport , Steven Price , "Maciej S . Szmigiero" , Vlastimil Babka , Vishal Annapurve , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com, aarcange@redhat.com, ddutile@redhat.com, dhildenb@redhat.com, Quentin Perret , Michael Roth , mhocko@suse.com, Muchun Song , wei.w.wang@intel.com, Will Deacon , Marc Zyngier Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1666033549; a=rsa-sha256; cv=none; b=8UUYvsgXGeIGpISfjpiWp222lGvoqQF1S0iQJ5NWPgDeO5YDhk0XbJat7MK3SamoowmBWI g6uggLg3exAon1W7RAMMY4VwPYgrLZ2aJvuGH0KzpwDmw08Ce4Ds1Oh+uybIZkwJskVXae EKHv6FUu7XdZPPKt6QwrXJXRkIlwQTM= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=cTXJI0UB; spf=pass (imf20.hostedemail.com: domain of tabba@google.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1666033549; h=from:from:sender: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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tpLbF7MUjfgdwKeolFrKwUGGJvkFHEynVfhNRIRYzO0=; b=bdfm3ZT3T8m/B+5TVkgb2acjK7ej8NlKfGKuQ7vFVY4l1/g1PnX9+oZ443WpFt3+vxUgNE /cJK4jj9CttZ5FZvG0Rkor33Bklyp2qTbE1dEBm4WiOH6r2JRaWn/fDifFNjwVLQk8Hf1V ewu6/QJlEdS/vQRwX5bLCQAPN+OKfHA= X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=cTXJI0UB; spf=pass (imf20.hostedemail.com: domain of tabba@google.com designates 209.85.208.176 as permitted sender) smtp.mailfrom=tabba@google.com; dmarc=pass (policy=reject) header.from=google.com X-Stat-Signature: ibfhzw9goj5o9yt419eic4mwrgm7okg7 X-Rspamd-Queue-Id: 03C091C0036 X-Rspamd-Server: rspam10 X-HE-Tag: 1666033548-575945 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi, > > > Using both private_fd and userspace_addr is only needed in TDX and other > > > confidential computing scenarios, pKVM may only use private_fd if the fd > > > can also be mmaped as a whole to userspace as Sean suggested. > > > > That does work in practice, for now at least, and is what I do in my > > current port. However, the naming and how the API is defined as > > implied by the name and the documentation. By calling the field > > private_fd, it does imply that it should not be mapped, which is also > > what api.rst says in PATCH v8 5/8. My worry is that in that case pKVM > > would be mis/ab-using this interface, and that future changes could > > cause unforeseen issues for pKVM. > > That is fairly enough. We can change the naming and the documents. > > > > > Maybe renaming this to something like "guest_fp", and specifying in > > the documentation that it can be restricted, e.g., instead of "the > > content of the private memory is invisible to userspace" something > > along the lines of "the content of the guest memory may be restricted > > to userspace". > > Some other candidates in my mind: > - restricted_fd: to pair with the mm side restricted_memfd > - protected_fd: as Sean suggested before > - fd: how it's explained relies on the memslot.flag. All these sound good, since they all capture the potential use cases. Restricted might be the most logical choice if that's going to also become the name for the mem_fd. Thanks, /fuad > Thanks, > Chao > > > > What do you think? > > > > Cheers, > > /fuad > > > > > > > > Thanks, > > > Chao > > > > > > > > Cheers, > > > > /fuad