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 72DCCC433F5 for ; Mon, 22 Nov 2021 15:10:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E81936B006C; Mon, 22 Nov 2021 10:10:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E31A86B0072; Mon, 22 Nov 2021 10:10:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CD1F96B0073; Mon, 22 Nov 2021 10:10:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id BF6C46B006C for ; Mon, 22 Nov 2021 10:10:08 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 85E7A824556B for ; Mon, 22 Nov 2021 15:09:58 +0000 (UTC) X-FDA: 78836901360.01.DA746DD Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by imf31.hostedemail.com (Postfix) with ESMTP id 209191052CBE for ; Mon, 22 Nov 2021 15:09:53 +0000 (UTC) Received: by mail-qt1-f176.google.com with SMTP id q14so16768403qtx.10 for ; Mon, 22 Nov 2021 07:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=5VTof+3edSRysBWJfMrn+QjeSl3KM16l29/PC/dx3o4=; b=GgW+p5PeHc0bQly0v21nzAJ3y6uv9j+6GJjj3/kSRMtOhXgQUdo630hHq9WFNfMw3+ 7jwm/pEg3OMqP3OSiHN9g6X2ApOK6D6i97qPCojv4hHg6bX3hTJX1VRV9wv9AJivwnTz NMbrhhMDJdFriocGD9Q87qSC2eg3XWgnsBQvzED4l/rtGH5c3J9RkR24eZLMQVocatzk 16fEwCdt4zSVbLzcMUR1znohS2vSzntWqte0ryaXUwXGyQptkpXIcQYp/zc6kdLcBhqC Cg6yB3MWTxm24NNgtuPBXuKgfkuCI4/QoYWo4AoHhvWYPVXt8w84jQYnFFi6M8A4ngDL vRoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=5VTof+3edSRysBWJfMrn+QjeSl3KM16l29/PC/dx3o4=; b=qJAz/28O5iMcpSxEk52BmJWTUOwYr4XPJYLIlyk3LN26NQkj1lL4GvnqZ12Zfg6fDr 8deXyWhz/ah/3fN4QnaGSsR78xq4TJNo1G2z3DyzMATSWVvpz/rmI2JMidXE9K/HPkco y8v5LXDuImBMKXu6YqTNMu+MZFi+9ok373W9YznzFU/5VXxKVS6U9kObHxFqp2vYRXNk biNdgZhdWV64/d4nZzMBYGZH9orqg/NXjTl4dbKLYixi7guITCnDnXBPi4XX6ayM6t70 OiXLnsnB0gQJOUmmRC+reEj6nqO46PyZEQO09YSp9Ojo3r084KRpW7iBDYGP6peXweuW u1Lg== X-Gm-Message-State: AOAM532vyN9zvHvCxs+PW7SdJW/H3ThstoBOHh8dzaDp3BAYeBlN2iqc PggSrbAPCAvvQkQAcc9EeBBRvQ== X-Google-Smtp-Source: ABdhPJyRLMA8XcwBk54ljNUHf6oDk+V6lmAhSa4hBpytn+jTTywY+jUzb27EMb9+9wB5t9Defs2Bqw== X-Received: by 2002:a05:622a:189:: with SMTP id s9mr31877263qtw.352.1637593797445; Mon, 22 Nov 2021 07:09:57 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-113-129.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.113.129]) by smtp.gmail.com with ESMTPSA id b9sm4563076qtb.53.2021.11.22.07.09.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Nov 2021 07:09:57 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1mpAxA-00DtLu-8c; Mon, 22 Nov 2021 11:09:56 -0400 Date: Mon, 22 Nov 2021 11:09:56 -0400 From: Jason Gunthorpe To: David Hildenbrand Cc: Chao Peng , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, qemu-devel@nongnu.org, 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 , Yu Zhang , "Kirill A . Shutemov" , luto@kernel.org, john.ji@intel.com, susie.li@intel.com, jun.nakajima@intel.com, dave.hansen@intel.com, ak@linux.intel.com Subject: Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST Message-ID: <20211122150956.GS876299@ziepe.ca> References: <20211119134739.20218-1-chao.p.peng@linux.intel.com> <20211119134739.20218-2-chao.p.peng@linux.intel.com> <20211119151943.GH876299@ziepe.ca> <20211119160023.GI876299@ziepe.ca> <4efdccac-245f-eb1f-5b7f-c1044ff0103d@redhat.com> <20211122133145.GQ876299@ziepe.ca> <56c0dffc-5fc4-c337-3e85-a5c9ce619140@redhat.com> <20211122140148.GR876299@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 209191052CBE X-Stat-Signature: e31zqmzrcxrzc56r119d8wmkncg3onkt Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=ziepe.ca header.s=google header.b=GgW+p5Pe; dmarc=none; spf=pass (imf31.hostedemail.com: domain of jgg@ziepe.ca designates 209.85.160.176 as permitted sender) smtp.mailfrom=jgg@ziepe.ca X-Rspamd-Server: rspam02 X-HE-Tag: 1637593793-544526 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 Mon, Nov 22, 2021 at 03:57:17PM +0100, David Hildenbrand wrote: > On 22.11.21 15:01, Jason Gunthorpe wrote: > > On Mon, Nov 22, 2021 at 02:35:49PM +0100, David Hildenbrand wrote: > >> On 22.11.21 14:31, Jason Gunthorpe wrote: > >>> On Mon, Nov 22, 2021 at 10:26:12AM +0100, David Hildenbrand wrote: > >>> > >>>> I do wonder if we want to support sharing such memfds between processes > >>>> in all cases ... we most certainly don't want to be able to share > >>>> encrypted memory between VMs (I heard that the kernel has to forbid > >>>> that). It would make sense in the use case you describe, though. > >>> > >>> If there is a F_SEAL_XX that blocks every kind of new access, who > >>> cares if userspace passes the FD around or not? > >> I was imagining that you actually would want to do some kind of "change > >> ownership". But yeah, the intended semantics and all use cases we have > >> in mind are not fully clear to me yet. If it's really "no new access" > >> (side note: is "access" the right word?) then sure, we can pass the fd > >> around. > > > > What is "ownership" in a world with kvm and iommu are reading pages > > out of the same fd? > > In the world of encrypted memory / TDX, KVM somewhat "owns" that memory > IMHO (for example, only it can migrate or swap out these pages; it's > might be debatable if the TDX module or KVM actually "own" these pages ). Sounds like it is a swap provider more than an owner? Jason