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 40936C00140 for ; Fri, 5 Aug 2022 13:28:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C20A88E0003; Fri, 5 Aug 2022 09:28:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF7118E0001; Fri, 5 Aug 2022 09:28:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A992B8E0003; Fri, 5 Aug 2022 09:28:56 -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 9BB318E0001 for ; Fri, 5 Aug 2022 09:28:56 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6F35D140602 for ; Fri, 5 Aug 2022 13:28:56 +0000 (UTC) X-FDA: 79765619472.16.8F6930F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf14.hostedemail.com (Postfix) with ESMTP id E220A100140 for ; Fri, 5 Aug 2022 13:28:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1659706135; 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=5LwXiW7Z9fPKOQuP6mWqJcS8w+uYP/AKU9h+QKQOqfY=; b=Q/oPvAzm+yT65mDJtPfKoMpPCpfPjnFDUuV6lK5QIEG6VR7qMSPeMULzI7G7SSndrJ3eNt YcF95heURkfGhPDALn/p1Cf77Hl/EqWjuLOSUmD6a+c/ErxQ2IXrKWUHMmjs9uP4RtPIEM /qehMpaCcDkneZ1dwAq8lyYDSWnIJGE= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-331-EJEfqcRINr-Tuo3LbolOnA-1; Fri, 05 Aug 2022 09:28:54 -0400 X-MC-Unique: EJEfqcRINr-Tuo3LbolOnA-1 Received: by mail-wr1-f71.google.com with SMTP id w17-20020adfbad1000000b0021f0acd5398so503657wrg.1 for ; Fri, 05 Aug 2022 06:28:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc; bh=5LwXiW7Z9fPKOQuP6mWqJcS8w+uYP/AKU9h+QKQOqfY=; b=zW7dSwwajnoYK7CGOb7GO/wVfgx4KU6intXKLzGCylGCTjda3/+LqXtL6gKi7cr/Na wzh7rAZL6aDCl5IS9DwYfzsq5D/0MJOBLQw/dCBEiZKln7WY9pklSHn7N1u0bxmNb5Ja X7wfAnqG8h+4Xu+9A/gPDOnvvsL/C9uws8LR3wLKMVTkMHyJWBDiboOJZc5Y/U3GQ7xq svFbVqJxfjlc2bsmpU+dUEBOOrGeMueEhETou+WUUYSG54IO2GGjvPo0/tmoMXFc2SQ7 MVMk09ymdp+BvFILi856bxsoqwCkEDezpN5CrAiORQTmajOI3gNTDDFmR/wgTbcNixQN G2zQ== X-Gm-Message-State: ACgBeo1a0dKIjou/A2JEHxD8lQACkywLmoY9FpiULo51Vo2cfRcyaQDd sX0v0YWfEs9tUCAwr+kZaXi8ZZBOeHPRIC6XppVino64jJ8gdoSCGsYGnJlUZda3SUOf+AvbqaP y6FyEjYmI0AM= X-Received: by 2002:a05:6000:1acf:b0:21d:b410:599a with SMTP id i15-20020a0560001acf00b0021db410599amr4119478wry.123.1659706133370; Fri, 05 Aug 2022 06:28:53 -0700 (PDT) X-Google-Smtp-Source: AA6agR4rDbFbn4pE0ENzxm72PrKdoCqlUokRwvGeNDRUB01hSQV7gEIr0bukiPJi7Qq8c2+e4UOfGA== X-Received: by 2002:a05:6000:1acf:b0:21d:b410:599a with SMTP id i15-20020a0560001acf00b0021db410599amr4119438wry.123.1659706133086; Fri, 05 Aug 2022 06:28:53 -0700 (PDT) Received: from ?IPV6:2003:cb:c706:fb00:f5c3:24b2:3d03:9d52? (p200300cbc706fb00f5c324b23d039d52.dip0.t-ipconnect.de. [2003:cb:c706:fb00:f5c3:24b2:3d03:9d52]) by smtp.gmail.com with ESMTPSA id ck19-20020a5d5e93000000b0021ee65426a2sm3893063wrb.65.2022.08.05.06.28.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Aug 2022 06:28:52 -0700 (PDT) Message-ID: <203c752f-9439-b5ae-056c-27b2631dcb81@redhat.com> Date: Fri, 5 Aug 2022 15:28:50 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v7 05/14] mm/memfd: Introduce MFD_INACCESSIBLE flag To: Chao Peng , 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, linux-kselftest@vger.kernel.org Cc: Paolo Bonzini , Jonathan Corbet , Sean Christopherson , 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 References: <20220706082016.2603916-1-chao.p.peng@linux.intel.com> <20220706082016.2603916-6-chao.p.peng@linux.intel.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20220706082016.2603916-6-chao.p.peng@linux.intel.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659706136; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5LwXiW7Z9fPKOQuP6mWqJcS8w+uYP/AKU9h+QKQOqfY=; b=dCVjoLrc1nYpcPzp3oww8GvOZ0BN2IYoSrqJRJSr8TWht37vS+IyBHTNmeUwEsWOjRipy3 S4x3LwSbvB7Moa5ipWzQF8LOt03M4r9RoXTEuwCvtAZUn9aI1o62Z8OTOblg4mABXAsyYT +S/rMLbx5wELIF/xUL6/QkvkjabT0TU= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Q/oPvAzm"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf14.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659706136; a=rsa-sha256; cv=none; b=LSJ2nIZbFcOI8w92GSVn3cJ2AdUf+Bcl3R9FEFdzPHuGT7w2fO6R0UV2sKmcph9O89KVY3 hsrgdo98GaNjacM7rz9ERhfcWXBF+BbfiuVe6ATSlAMJZfECP+fcdO73DDZrb4TpRgovnk ccvQ3yEyp5mIsZtDHbimS5UfpEfQqk0= X-Stat-Signature: nuji7zpoe98x4tamqssey97cwxryajan X-Rspamd-Queue-Id: E220A100140 X-Rspamd-Server: rspam01 Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="Q/oPvAzm"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf14.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com X-Rspam-User: X-HE-Tag: 1659706135-115565 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: On 06.07.22 10:20, Chao Peng wrote: > Introduce a new memfd_create() flag indicating the content of the > created memfd is inaccessible from userspace through ordinary MMU > access (e.g., read/write/mmap). However, the file content can be > accessed via a different mechanism (e.g. KVM MMU) indirectly. > > It provides semantics required for KVM guest private memory support > that a file descriptor with this flag set is going to be used as the > source of guest memory in confidential computing environments such > as Intel TDX/AMD SEV but may not be accessible from host userspace. > > The flag can not coexist with MFD_ALLOW_SEALING, future sealing is > also impossible for a memfd created with this flag. It's kind of weird to have it that way. Why should the user have to care? It's the notifier requirement to have that, no? Why can't we handle that when register a notifier? If anything is already mapped, fail registering the notifier if the notifier has these demands. If registering succeeds, block it internally. Or what am I missing? We might not need the memfile set flag semantics eventually and would not have to expose such a flag to user space. -- Thanks, David / dhildenb