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 C088AC00140 for ; Wed, 24 Aug 2022 10:25:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4A8B56B0073; Wed, 24 Aug 2022 06:25:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 457AC940008; Wed, 24 Aug 2022 06:25:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F7A6940007; Wed, 24 Aug 2022 06:25:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 209C56B0073 for ; Wed, 24 Aug 2022 06:25:54 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E2AD7AC15D for ; Wed, 24 Aug 2022 10:25:53 +0000 (UTC) X-FDA: 79834105386.03.CEA2B8C Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf02.hostedemail.com (Postfix) with ESMTP id 194C58003E for ; Wed, 24 Aug 2022 10:25:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1661336752; x=1692872752; h=date:from:to:cc:subject:message-id:reply-to:references: mime-version:in-reply-to; bh=ov6LWOeGKE0o/d22MV9D8SJ+ovEHwDZEA5oKgTfWHCI=; b=LTwPgRQam6tS1IsD3dpUwr7fcu9fjmoRjI/qDOsQjxkmHPJ8tba19EFY x+Qwz6pyqF14d1xwY2uAf4oFkZFiN9nlNK1bYuOKog5kp8ZqXfJue1XD1 hYbSuPOwJSrKyEI3VZ9FdBXzVq+MMtEAdlIKA+AsWGo0lixXfieFDyBj6 JaHBu24NlHttmwxtkuv1C+/Ep+4htUCXlhJmRgUUqRDg1ZrEXSN98jC3G ft2MSeW+KxcuBscwmAK9y+uYtQ4GTB4b8xh21NSMDnb9p0cVhMb02kvQG TKsvGZ2oaUCaXWNVpgTHTjwOv6SXSm0XhhDip3SatxkFKAJmziI/rkmmq A==; X-IronPort-AV: E=McAfee;i="6500,9779,10448"; a="276953879" X-IronPort-AV: E=Sophos;i="5.93,260,1654585200"; d="scan'208";a="276953879" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Aug 2022 03:25:50 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.93,260,1654585200"; d="scan'208";a="605986064" Received: from chaop.bj.intel.com (HELO localhost) ([10.240.193.75]) by orsmga007.jf.intel.com with ESMTP; 24 Aug 2022 03:25:39 -0700 Date: Wed, 24 Aug 2022 18:20:56 +0800 From: Chao Peng To: David Hildenbrand Cc: "Kirill A. Shutemov" , Paolo Bonzini , 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, 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 Subject: Re: [PATCH v7 01/14] mm: Add F_SEAL_AUTO_ALLOCATE seal to memfd Message-ID: <20220824102056.GA1385482@chaop.bj.intel.com> Reply-To: Chao Peng References: <20220706082016.2603916-1-chao.p.peng@linux.intel.com> <20220706082016.2603916-2-chao.p.peng@linux.intel.com> <472207cf-ff71-563b-7b66-0c7bea9ea8ad@redhat.com> <20220817234120.mw2j3cgshmuyo2vw@box.shutemov.name> <8f6f428b-85e6-a188-7f32-512b6aae0abf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f6f428b-85e6-a188-7f32-512b6aae0abf@redhat.com> ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=LTwPgRQa; spf=none (imf02.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1661336752; a=rsa-sha256; cv=none; b=cRbU48dYajcZCtl6tSaM8sLd/ePdKIwLf/oy5N8cf2cnDcJQvW8If7mIIpF6ZOmYD6HQe5 D5PKxbHbR3uL66Z1ZgidGDdXzKWm2B1Cdmabhn3hOpyITwtrtLmSKDqyIgeoG8Fm4qDfz2 rKirUD+fjf3bJd5VglPbUpR4NQYOTRk= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1661336752; h=from:from:sender:reply-to: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=rgCX/X0mhD9vcjCFqBICNAdDViUPiHoy3xUWZglQdFs=; b=CTKCzYBkcAHAeuEzIR7hpxIdrmcFe/++VN+q75splhb2dILgP6GySkF5FEDx2i0G7WTNVI xn+Ql67EVsi6tvRU+A456G53laaVUJFxbfTYlsrgLjPwD9+NMqkTMCbaahuS4/DLK/14aa fSiCLWisCSSIC76OJ91tIi7ueoPHHFA= Authentication-Results: imf02.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=LTwPgRQa; spf=none (imf02.hostedemail.com: domain of chao.p.peng@linux.intel.com has no SPF policy when checking 134.134.136.126) smtp.mailfrom=chao.p.peng@linux.intel.com; dmarc=fail reason="No valid SPF" header.from=intel.com (policy=none) X-Rspam-User: X-Rspamd-Queue-Id: 194C58003E X-Rspamd-Server: rspam05 X-Stat-Signature: sep19satw974wxu9k6sy9ehy48prooqa X-HE-Tag: 1661336751-108612 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 Tue, Aug 23, 2022 at 09:36:57AM +0200, David Hildenbrand wrote: > On 18.08.22 01:41, Kirill A. Shutemov wrote: > > On Fri, Aug 05, 2022 at 07:55:38PM +0200, Paolo Bonzini wrote: > >> On 7/21/22 11:44, David Hildenbrand wrote: > >>> > >>> Also, I*think* you can place pages via userfaultfd into shmem. Not > >>> sure if that would count "auto alloc", but it would certainly bypass > >>> fallocate(). > >> > >> Yeah, userfaultfd_register would probably have to forbid this for > >> F_SEAL_AUTO_ALLOCATE vmas. Maybe the memfile_node can be reused for this, > >> adding a new MEMFILE_F_NO_AUTO_ALLOCATE flags? Then userfault_register > >> would do something like memfile_node_get_flags(vma->vm_file) and check the > >> result. > > > > I donno, memory allocation with userfaultfd looks pretty intentional to > > me. Why would F_SEAL_AUTO_ALLOCATE prevent it? > > > > Can't we say the same about a write()? > > > Maybe we would need it in the future for post-copy migration or something? > > > > Or existing practises around userfaultfd touch memory randomly and > > therefore incompatible with F_SEAL_AUTO_ALLOCATE intent? > > > > Note, that userfaultfd is only relevant for shared memory as it requires > > VMA which we don't have for MFD_INACCESSIBLE. > > This feature (F_SEAL_AUTO_ALLOCATE) is independent of all the lovely > encrypted VM stuff, so it doesn't matter how it relates to MFD_INACCESSIBLE. Right, this patch is for normal user accssible fd. In KVM this flag is expected to be set on the shared part of the memslot, while all other patches in this series are for private part of the memslot. Private memory doesn't have this need because it's totally inaccissible from userspace so no chance for userspace to write to the fd and cause allocation by accident. While for shared memory, malicious/buggy guest OS may cause userspace to write to any range of the shared fd and cause memory allocation, even that range should the private memory not the shared memory be visible to guest OS. Chao > > -- > Thanks, > > David / dhildenb >