Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp4889876rwi; Mon, 17 Oct 2022 12:11:32 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5Da0esNeCcbw+26+FooYSqTKb+UpKMuP+UcgNS6xXk438TTUDZ7h4VJZOfFZxnIvOefn6o X-Received: by 2002:aa7:cad5:0:b0:454:88dc:2c22 with SMTP id l21-20020aa7cad5000000b0045488dc2c22mr11788745edt.352.1666033892500; Mon, 17 Oct 2022 12:11:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666033892; cv=none; d=google.com; s=arc-20160816; b=o3eNbEg8OMGd534XWQyFSH6s2qmQ2GLRWvEd3r9cJqk1q/lCm3wRS5bjpvKX3dYGRP 5l7prD6zQ4GorCJ80bOSf5nJqUwXGvfvRI3lsIUNR8y0VJ/Q7KsaZ1jDQM3QN3VsRHx8 9Bq+mEEfuCf65L665IedZQFJHieol92+p1ZDZSPBmCV2ewG3tVJuw+QNSlBbtcp1UE1E yomjDtWgW8xAL54oMzjQlv/Kv9SJ3gapaM6r5BKWbeTgKQCEO1VQ1+r2KM7IV8aXEDEm viZQeiQvbUD+9cm48gi6HTTyz8Nd9If/LTiepZfuGAezDvRr315gGT1/bpxOl5NfrCau 6TfA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=tpLbF7MUjfgdwKeolFrKwUGGJvkFHEynVfhNRIRYzO0=; b=GG+8mWnHcJup+6yH8nYb8KOOPAW9xCJeP0Scrh7YPH46rlmXhdek/mnP7Upw5pFF9x csPe4Uqo3VMtWiRolnQfSg8QceWbiXSfmc2K9FjiY+YpzirPKY29DSCbExsdnRvshTMj TFaBk4zPE7BBS6wPDKK/kqPD0tyQAuIdRcUqYra6lc9v9eWZ5JADj4dyBeC6x3NmCnN1 kniyojAirsEd18bGG99aAj2MXLP4TY/hDZRN0eVLeXZjNfyd3Wm8oHhbvuFtIwRPJi8+ D4C9s5QBdOV+e2m7ppXrt3+ibxokeOdgAEURxWghBMvUPqiPXUU3sdtGj5N/KGkCMlf0 s3VQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=cTXJI0UB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id mp14-20020a1709071b0e00b0078198611a45si9361295ejc.980.2022.10.17.12.11.07; Mon, 17 Oct 2022 12:11:32 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=cTXJI0UB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230171AbiJQTFx (ORCPT + 99 others); Mon, 17 Oct 2022 15:05:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44646 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230119AbiJQTFv (ORCPT ); Mon, 17 Oct 2022 15:05:51 -0400 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB55658B43 for ; Mon, 17 Oct 2022 12:05:48 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id r22so15125097ljn.10 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=e+bBBa8b2CSAEakIjQz6auXJgs5M6Y0DIixaGNS7gBKq0sALDSQ6oCRtWXXfxYW9VJ W4WPW3qpYSDk1gnz1eukMNHbL06bXya0OWDDxBK/WMFNrctEalJ81RlVgaA5LhcP+VLD ZTflFsl56ErLmrqZOAYVgMQhf7stHfknSkkvx5dImtcJVFjOZ0YEjmYMix65AXRc0LCM 4t0PnKhxJaK0aS7rkIsbSTzuscQFZZqhrstEhbgjlZn4B8YnTLCWwVq7dSZY+Aa6s2cm lIqzELYCCOIl1HbpmFE58HJoKlFZDs8pB1llSzNpp1Q/w9EGbvBhye6r6YHAsCM+BAME UiKw== X-Gm-Message-State: ACrzQf0sqpIRN0nr45MSjZDEIVLYiqGc+sZgKuUvFy51+FcQtzJl5/hE R6Mbi4XWlt5mOF0WAMJkpsc5zSGxzppZsvSPHl8Niw== 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" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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