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 24CECC3DA42 for ; Wed, 10 Jul 2024 09:50:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AA19B6B0085; Wed, 10 Jul 2024 05:50:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A534D6B0089; Wed, 10 Jul 2024 05:50:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 91A2A6B008A; Wed, 10 Jul 2024 05:50:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 73DFD6B0085 for ; Wed, 10 Jul 2024 05:50:45 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 14340161BC9 for ; Wed, 10 Jul 2024 09:50:45 +0000 (UTC) X-FDA: 82323373650.03.0C633C1 Received: from smtp-fw-52005.amazon.com (smtp-fw-52005.amazon.com [52.119.213.156]) by imf03.hostedemail.com (Postfix) with ESMTP id 285E220003 for ; Wed, 10 Jul 2024 09:50:42 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=amazon.co.uk header.s=amazon201209 header.b=GWN7TO4G; dmarc=pass (policy=quarantine) header.from=amazon.co.uk; spf=pass (imf03.hostedemail.com: domain of "prvs=914e10141=roypat@amazon.co.uk" designates 52.119.213.156 as permitted sender) smtp.mailfrom="prvs=914e10141=roypat@amazon.co.uk" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1720605017; a=rsa-sha256; cv=none; b=w1ez8G77AMogXgmstUzptL/7qKj9lbfwWQ8DnrOoZ1AiG8SS2OWulIw01UWN8cU6BydpaF qTQq+UPKbqgoO8h24IBYjq2PZnU9j9ATvUKAsm46MZc/pVnLaUqC4aUBKAVXsDfqrx0dn7 WFO9CERbMa0sjqhHQCO4wPNgpSHJDeE= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=amazon.co.uk header.s=amazon201209 header.b=GWN7TO4G; dmarc=pass (policy=quarantine) header.from=amazon.co.uk; spf=pass (imf03.hostedemail.com: domain of "prvs=914e10141=roypat@amazon.co.uk" designates 52.119.213.156 as permitted sender) smtp.mailfrom="prvs=914e10141=roypat@amazon.co.uk" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1720605017; 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=DnO9vyxIjhRPaz3em9T0G9QiR6aV7OUdcc5EJkgzZRY=; b=KbVKdBb1Sn0vgaQ9kRZfNUsnGg+NqwIcmKkuh2nbjeUpLaql70J73r8HL1/0Dg9MZQg6AE PCSnagxqdMvY3LwwAuoDyeoX9nHyNMOS3tJ5tXQlyctbmyrHnUFdhl296lsAF2qH2wxflH lswmAXRT2XW+Ko+RrPkGGNGNnGnlbaI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amazon.co.uk; i=@amazon.co.uk; q=dns/txt; s=amazon201209; t=1720605044; x=1752141044; h=message-id:date:mime-version:to:cc:references:from: in-reply-to:content-transfer-encoding:subject; bh=DnO9vyxIjhRPaz3em9T0G9QiR6aV7OUdcc5EJkgzZRY=; b=GWN7TO4GUYDWnDQOT2dZXZ7Htn+8CurOT8PaCVlV/Oa+3DaTqSWhFpGo CPLDYPORwl0Qc/vm2Xyg2cEXFE4vuer00iE91qjZxEqSdmyOeTaBaYpcN iUPx9xI/5yo1FGxGZXvo5ED/QhWS73KpEBpQxC4XwFsqJHJo1Vj62k4mw 0=; X-IronPort-AV: E=Sophos;i="6.09,197,1716249600"; d="scan'208";a="666251251" Subject: Re: [RFC PATCH 7/8] mm: secretmem: use AS_INACCESSIBLE to prohibit GUP Received: from iad12-co-svc-p1-lb1-vlan3.amazon.com (HELO smtpout.prod.us-west-2.prod.farcaster.email.amazon.dev) ([10.43.8.6]) by smtp-border-fw-52005.iad7.amazon.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2024 09:50:40 +0000 Received: from EX19MTAUWB001.ant.amazon.com [10.0.38.20:41730] by smtpin.naws.us-west-2.prod.farcaster.email.amazon.dev [10.0.19.144:2525] with esmtp (Farcaster) id 82a19754-40f2-4c44-87d8-6c4b9cb6e7ce; Wed, 10 Jul 2024 09:50:38 +0000 (UTC) X-Farcaster-Flow-ID: 82a19754-40f2-4c44-87d8-6c4b9cb6e7ce Received: from EX19D020UWC002.ant.amazon.com (10.13.138.147) by EX19MTAUWB001.ant.amazon.com (10.250.64.248) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34; Wed, 10 Jul 2024 09:50:37 +0000 Received: from EX19MTAUWB001.ant.amazon.com (10.250.64.248) by EX19D020UWC002.ant.amazon.com (10.13.138.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34; Wed, 10 Jul 2024 09:50:36 +0000 Received: from [127.0.0.1] (172.19.88.180) by mail-relay.amazon.com (10.250.64.254) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.2.1258.34 via Frontend Transport; Wed, 10 Jul 2024 09:50:31 +0000 Message-ID: <258b3b76-cf87-4dfc-bcfa-b2af94aba811@amazon.co.uk> Date: Wed, 10 Jul 2024 10:50:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Mike Rapoport , David Hildenbrand CC: , , , , , , , , , , , , , , , , , , , , , James Gowans References: <20240709132041.3625501-1-roypat@amazon.co.uk> <20240709132041.3625501-8-roypat@amazon.co.uk> <0dc45181-de7e-4d97-9178-573c6f683f55@redhat.com> Content-Language: en-US From: Patrick Roy Autocrypt: addr=roypat@amazon.co.uk; keydata= xjMEY0UgYhYJKwYBBAHaRw8BAQdA7lj+ADr5b96qBcdINFVJSOg8RGtKthL5x77F2ABMh4PN NVBhdHJpY2sgUm95IChHaXRodWIga2V5IGFtYXpvbikgPHJveXBhdEBhbWF6b24uY28udWs+ wpMEExYKADsWIQQ5DAcjaM+IvmZPLohVg4tqeAbEAgUCY0UgYgIbAwULCQgHAgIiAgYVCgkI CwIEFgIDAQIeBwIXgAAKCRBVg4tqeAbEAmQKAQC1jMl/KT9pQHEdALF7SA1iJ9tpA5ppl1J9 AOIP7Nr9SwD/fvIWkq0QDnq69eK7HqW14CA7AToCF6NBqZ8r7ksi+QLOOARjRSBiEgorBgEE AZdVAQUBAQdAqoMhGmiXJ3DMGeXrlaDA+v/aF/ah7ARbFV4ukHyz+CkDAQgHwngEGBYKACAW IQQ5DAcjaM+IvmZPLohVg4tqeAbEAgUCY0UgYgIbDAAKCRBVg4tqeAbEAtjHAQDkh5jZRIsZ 7JMNkPMSCd5PuSy0/Gdx8LGgsxxPMZwePgEAn5Tnh4fVbf00esnoK588bYQgJBioXtuXhtom 8hlxFQM= In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 285E220003 X-Stat-Signature: bx7b8mmmp1ughd73pmdp33hcatceg9ti X-Rspam-User: X-HE-Tag: 1720605042-822341 X-HE-Meta: U2FsdGVkX1+UJecBRDeHaJwDkbQqoGY1zouQECtVJv6ElMAwtPc84wdl2snuAehpI8qZxgauWg6fhy2oW9yydK+JuM+nl7r9vqyUKF6zyPuRgBU9FgrQHh0p/Bz/lShKWv16UPgcIQKPaPTLrYielJFkvxEiXMZ4G3AvnobINNx1Dvd/tpyOv5bEat6f76tWMmcqhPUgER0oSCzJJjAeIOAT+6CDi8vmcnZ3KIv4WUmkRcaOwtDEbYUyNqPEmKUR2QYGPH8vi7f48qKSGtRD24wKbIl+Xc94jcYf29D0L/j4zr+VLT7r3JZDggbZz0BOgtHhiC5lz6SwtVwSMmaLmyLcvA1YCtwRR97Vzl7FEzWkaN2+TkCkvMTQmKzw0a5hiP6KQORv//0Ww2MgpzR08tOpEGE3fq03wi5NglMm2zobgKJkMoVmVJQtD5KKn+NYfUNinK/ePOo3IAgEYlEEwzAA3SuqKwU2z0reE2YCJovs4duvl1h9TKWoQ7fqYydo3XOGpUXwv1jtgJv7AdYhtFXtWgqE9rzSza1e4/1XAYcEEVq2J/O3W56L2ZYkPeuwPHnyT0g5ygnNCiSvSf+PPFEta9ZiXNpmJEAumuwBXDdEJlNdB5eC1NXOnjFmjA4EAODOA2X1jDbFLUxOxKwMlaIXpLZFK1w6Np83uOrq0TBM24ZBMDisnyMkje7Njgr4KU1n66DmfRm9IBTrB4D/8nnnAsEXcFyQOgzHvs0IYiObWBAxeMiUX9UO2mg4ntzx1ZyoHfXN4vZmnjeOwINA4Kfx6z1mh4ljJ0VZSmpauFaBsCh4Yzo4flPVmsEqe0MaEvJDZURtID9XHVcow6m+qt/Su7Lfbhi0TylrmKXWI2xFT5ejZcqzdmT1yVl+8lrFAQU2A30iXK0dA5s9kH86f+R5ybxAnEYiVRSc2MdwlTImYdqccCoD5jVHm5KNLVE8d6GX4CzlsRNfqKzD4Ch TDpSKuyK 8K1jbcjAzy7j7sfkrl0ZafCkNdNHZQmMemlH2+xbxuEaCPx8DqolmtQSom44KXHubYIH5ADMhk74etyff9IJkNBmBlfjnBLt8/Tp1dhKBD3Z8yX9hfHIZKccpMmGOoF11FJS9uL/L7SOzklnNUsnxijxEM8otvMre4EoSst+h1zHbLO8qCZoOjHzk4pOSeV+6+42CljdGSag7Vjt3niujz7ZJC+MBX88aNZMsize8AECWzhJXpSC1BWWfmmG/7gGWYLrJ/AAiGtGkn7bSPR7pSOQFM2VB+VwoHHWM3iiMeKes8YAkeJ8kiWbwQYKO85VbWXxED4tJWex4tSpU5OyQ3FeeOEqAhsaApQDYxcopod0gzueZL+VjAhf+xNGv6jCY4+jNj1hP3M1wtGFfoglAYJUpB4OODdhQbYmshJXjAx4aV+MwELxwNXJI/SfoxKOH5tlx8Qx+CEutGY9bObDNvi6tC5J5jB95Ssu9C2LBoovzBLt3st2GxepiSg== 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: List-Subscribe: List-Unsubscribe: On 7/10/24 08:32, Mike Rapoport wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > On Tue, Jul 09, 2024 at 11:09:29PM +0200, David Hildenbrand wrote: >> On 09.07.24 15:20, Patrick Roy wrote: >>> Inside of vma_is_secretmem and secretmem_mapping, instead of checking >>> whether a vm_area_struct/address_space has the secretmem ops structure >>> attached to it, check whether the address_space has the AS_INACCESSIBLE >>> bit set. Then set the AS_INACCESSIBLE flag for secretmem's >>> address_space. >>> >>> This means that get_user_pages and friends are disables for all >>> adress_spaces that set AS_INACCESIBLE. The AS_INACCESSIBLE flag was >>> introduced in commit c72ceafbd12c ("mm: Introduce AS_INACCESSIBLE for >>> encrypted/confidential memory") specifically for guest_memfd to indicate >>> that no reads and writes should ever be done to guest_memfd >>> address_spaces. Disallowing gup seems like a reasonable semantic >>> extension, and means that potential future mmaps of guest_memfd cannot >>> be GUP'd. >>> >>> Signed-off-by: Patrick Roy >>> --- >>> include/linux/secretmem.h | 13 +++++++++++-- >>> mm/secretmem.c | 6 +----- >>> 2 files changed, 12 insertions(+), 7 deletions(-) >>> >>> diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h >>> index e918f96881f5..886c8f7eb63e 100644 >>> --- a/include/linux/secretmem.h >>> +++ b/include/linux/secretmem.h >>> @@ -8,10 +8,19 @@ extern const struct address_space_operations secretmem_aops; >>> static inline bool secretmem_mapping(struct address_space *mapping) >>> { >>> - return mapping->a_ops == &secretmem_aops; >>> + return mapping->flags & AS_INACCESSIBLE; >>> +} >>> + >>> +static inline bool vma_is_secretmem(struct vm_area_struct *vma) >>> +{ >>> + struct file *file = vma->vm_file; >>> + >>> + if (!file) >>> + return false; >>> + >>> + return secretmem_mapping(file->f_inode->i_mapping); >>> } >> >> That sounds wrong. You should leave *secretmem alone and instead have >> something like inaccessible_mapping that is used where appropriate. >> >> vma_is_secretmem() should not suddenly succeed on something that is not >> mm/secretmem.c > > I'm with David here. > Right, that makes sense. My thinking here was that if memfd_secret and potential mappings of guest_memfd have the same behavior wrt GUP, then it makes sense to just have them rely on the same checks. But I guess I didn't follow that thought to its logical conclusion of renaming the "secretmem" checks into "inaccessible" checks and moving them out of secretmem.h. Or do you mean to just leave secretmem untouched and add separate "inaccessible" checks? But then we'd have two different ways of disabling GUP for specific VMAs that both rely on checks in exactly the same places :/ >> -- >> Cheers, >> >> David / dhildenb >> > > -- > Sincerely yours, > Mike.