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 4EFADC433F5 for ; Mon, 22 Nov 2021 13:36:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7C276B0071; Mon, 22 Nov 2021 08:36:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A048A6B0072; Mon, 22 Nov 2021 08:36:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 87DDB6B0073; Mon, 22 Nov 2021 08:36:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0037.hostedemail.com [216.40.44.37]) by kanga.kvack.org (Postfix) with ESMTP id 73C706B0071 for ; Mon, 22 Nov 2021 08:36:05 -0500 (EST) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 380EB824C451 for ; Mon, 22 Nov 2021 13:35:55 +0000 (UTC) X-FDA: 78836664270.15.648FE37 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf25.hostedemail.com (Postfix) with ESMTP id 6CB5FB0002BC for ; Mon, 22 Nov 2021 13:35:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1637588154; 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=602lNvVOZar2m+HSFbxBYiyDNXrGO+dVi/Ze/KZAj6g=; b=ZNDVdueQ4xrwWe5pXhJgvmseao91pgGi4k943MKsjUnPjFhJBevrarVBZ/Y/Ght0GUGvXk FmHMfDzufOBWB+sPHo6bKBVpkZ+lMUvw/XAK8svFtTb9U9RdnRxN1+r6M/Y5LPG17FVzoR 9xfdcuB2bWSuUu1Z0DjXDXXh6biDfrs= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-325-2GEk8TM_Pa2HbEwR5POhDg-1; Mon, 22 Nov 2021 08:35:53 -0500 X-MC-Unique: 2GEk8TM_Pa2HbEwR5POhDg-1 Received: by mail-wr1-f70.google.com with SMTP id b1-20020a5d6341000000b001901ddd352eso3129147wrw.7 for ; Mon, 22 Nov 2021 05:35:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=602lNvVOZar2m+HSFbxBYiyDNXrGO+dVi/Ze/KZAj6g=; b=Ep+kSnrItm1E5EH6uWR0YbyW/9HcqLpGg0EI7PPMGhMqjnZVDTCOejQq8piE3gs/QO rlGYezwAfLUzePtYJXpr/QPNTowBUao5BrPD29eWWalTrdtHwCPHP8HEHHgU5i2+XclF pIVLHQ+QXtgRcZE32ZSYuykUQ2PA3EMUmfhEbXqVB5f38SIPhhOa9wE2Srcbs2TnezR7 K3/Gaumf/Aq/GGqEKA2c1Ex8Y2VHY4Arq8tTVIGra4ORAGMtmrHP57JuFtFCHZlwfjlO X5DyJS5HzA0b8ysRMyugf1tusxlD/oowrLcqLVA2MIDxt2BvAlAlDcdw0sbNDmmCcedX Ue9g== X-Gm-Message-State: AOAM533NcWtjGdWQUu6q2xG/yCrsoiQlmaxs2gXyvkO3m99vdeKzgn07 xDbtGr2Yke8NGNIRj9ECYoIpPvYuQLr4tPwbrGh2tARzAzo1gkqu89JArbwaSi0d1whL4vtQYkj mL3Lksz6QS20= X-Received: by 2002:adf:f042:: with SMTP id t2mr39515207wro.180.1637588151974; Mon, 22 Nov 2021 05:35:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJw1uMKJXFglAoRaU5wdp0h6HMWbMcVgb35JuanaPUNLoA7JZ4ctjynARZIlt7KcqMq8Cl1Yqg== X-Received: by 2002:adf:f042:: with SMTP id t2mr39515155wro.180.1637588151703; Mon, 22 Nov 2021 05:35:51 -0800 (PST) Received: from [192.168.3.132] (p5b0c667b.dip0.t-ipconnect.de. [91.12.102.123]) by smtp.gmail.com with ESMTPSA id m34sm24540329wms.25.2021.11.22.05.35.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Nov 2021 05:35:51 -0800 (PST) Message-ID: <56c0dffc-5fc4-c337-3e85-a5c9ce619140@redhat.com> Date: Mon, 22 Nov 2021 14:35:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [RFC v2 PATCH 01/13] mm/shmem: Introduce F_SEAL_GUEST To: Jason Gunthorpe 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 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> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20211122133145.GQ876299@ziepe.ca> 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 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 6CB5FB0002BC X-Stat-Signature: otugg5cxb7jt54mad18z9pb6843uydqt Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ZNDVdueQ; spf=none (imf25.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1637588152-421180 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 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. -- Thanks, David / dhildenb