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 B48A1C3ABD8 for ; Wed, 14 May 2025 13:32:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5DD7C6B014C; Wed, 14 May 2025 09:32:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 565826B014D; Wed, 14 May 2025 09:32:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DE3F6B014E; Wed, 14 May 2025 09:32:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 1D9476B014C for ; Wed, 14 May 2025 09:32:50 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 7C64180974 for ; Wed, 14 May 2025 13:32:51 +0000 (UTC) X-FDA: 83441603742.10.88BB5AA Received: from mail-pg1-f202.google.com (mail-pg1-f202.google.com [209.85.215.202]) by imf08.hostedemail.com (Postfix) with ESMTP id 98A24160006 for ; Wed, 14 May 2025 13:32:49 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3R4Sxn12; spf=pass (imf08.hostedemail.com: domain of 3gJskaAYKCJEDzv84x19916z.x97638FI-775Gvx5.9C1@flex--seanjc.bounces.google.com designates 209.85.215.202 as permitted sender) smtp.mailfrom=3gJskaAYKCJEDzv84x19916z.x97638FI-775Gvx5.9C1@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=3R4Sxn12; spf=pass (imf08.hostedemail.com: domain of 3gJskaAYKCJEDzv84x19916z.x97638FI-775Gvx5.9C1@flex--seanjc.bounces.google.com designates 209.85.215.202 as permitted sender) smtp.mailfrom=3gJskaAYKCJEDzv84x19916z.x97638FI-775Gvx5.9C1@flex--seanjc.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747229569; 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=RtedgjrSq1v3wZQaGrNE6v5R8N01W2PT/oJAJN+tLO0=; b=EZuIAjy8+2h4UI9PvJBuq7fWGH+1k0BqDY/DNlvlOqP5KT1i+Y3GJSqJNnyqAy2JMQnAp3 ZvY/0rIh1tt/Lj9wlkkD51Obv2L+rsC0XMY1cjxWLpT3lqmp/fDQbwWIUKGHglaPuO9BOO ddeesKFBYsBs/HZQPAbo0ah24YmddcY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747229569; a=rsa-sha256; cv=none; b=H5GFsCIoZGBfRg7aWVAnYHOu2CrEWDOy5udkx7R/yqWRVAJGH2hPiDe9cvnk6znpEG/njV KzZ2h6sKCqxv8RmMATuG43xomeoExn/Bcky5dgFnN0GCstafxXYWw4i6+ri4cSRcw3NIW0 5oDt3RmNXPdmrIg1yM70Nwb2fbQnjkk= Received: by mail-pg1-f202.google.com with SMTP id 41be03b00d2f7-b0e5f28841dso4282712a12.2 for ; Wed, 14 May 2025 06:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1747229568; x=1747834368; darn=kvack.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=RtedgjrSq1v3wZQaGrNE6v5R8N01W2PT/oJAJN+tLO0=; b=3R4Sxn12dt76nMqk7b5pPikmE1W+GUQGEaApyknpJ2/Ppk3JcrIDUZhne+emsMfgT0 UqEHavzPAkteMMXFQv0+mTPl2UMoBNgYe3ELPrw8d5dy/nlzmyT94mJZwK0kUB8lGl0h ooOJqV+Zk9tvJ+GznhcdTyXbeANvBMb1tC1s/ifix9M/j4BO7LzFZHecTTM4FqP0/0my mDKRyPrqe/mjf4An10KSNJV8Y9/x/M5FkCgaGSEqu+8IvW2Imn6x3bCFU/AS1LRnceUe 8+tyHgnsC6Fna3kWrerF8/EJ/7En3KxsU0xpZIGAOOvVaWqGjROud6iT20bjDR7iLEzl y6Nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747229568; x=1747834368; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=RtedgjrSq1v3wZQaGrNE6v5R8N01W2PT/oJAJN+tLO0=; b=Tu4+pQmK1TKgTYLbwmfEx4OBgfnNW1JBcuLQbICPHzjLJFC8nlFTVFJyFGGrTakriR RqOSi+fi2u/5v8Rw2HKDD0nlKki0TYoF+BYR8uOV4weRTfwfG0aQoDq8BPSoQCylz3DA gHeUu1STDiWcD1ERv+BKy0s6k2mQxM/PQCTT61xexhYuH6zQsqX7mhjBhP2oI/9wG0z/ 9rM2oGt5cwiNJyDeBbYCmYUKtqePKF9fWvoqJTwShPOAJJ6G48SdAwT6gDv56u+354vi q+bnQUlJJuSYexYAgF9RQO1yAp7BXVwaS5NoIWZeNhIK0C3W6ik8ocCeXUkANOk+H948 UWzQ== X-Forwarded-Encrypted: i=1; AJvYcCUMO0LTZ5HvLO51WhCg+hpzxTdh+Z+PIYl2cFL8CliaoFWHSC58d6ZoS9C3S8dbGJ0hNc+EvJ8w2Q==@kvack.org X-Gm-Message-State: AOJu0YyjDeWo//tL+rUIgYDpLN9RG6oSmkkZ5S6x5V3UHIwtcmhWGFYR sj0h7N3iBCO+UNfhAS48YuNlVhpyXLlyPsmAwLk6TcZBN+89tr9+To4jwOjcyAWBFoMcyAYWoYH g8Q== X-Google-Smtp-Source: AGHT+IEBESmhDh1kZA9q3dK9bozi69K8VuHlCLiyf6hF2yMudSAXgRJciMpW68u3/8oFdg4WPhCaXZrhSmQ= X-Received: from pjbpb18.prod.google.com ([2002:a17:90b:3c12:b0:2f5:63a:4513]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:58cf:b0:2fa:f8d:65de with SMTP id 98e67ed59e1d1-30e2e62a98emr4631512a91.22.1747229568217; Wed, 14 May 2025 06:32:48 -0700 (PDT) Date: Wed, 14 May 2025 06:32:46 -0700 In-Reply-To: Mime-Version: 1.0 References: <20250513163438.3942405-1-tabba@google.com> <20250513163438.3942405-9-tabba@google.com> Message-ID: Subject: Re: [PATCH v9 08/17] KVM: guest_memfd: Check that userspace_addr and fd+offset refer to same range From: Sean Christopherson To: Fuad Tabba Cc: James Houghton , kvm@vger.kernel.org, linux-arm-msm@vger.kernel.org, linux-mm@kvack.org, pbonzini@redhat.com, chenhuacai@kernel.org, mpe@ellerman.id.au, anup@brainfault.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, viro@zeniv.linux.org.uk, brauner@kernel.org, willy@infradead.org, akpm@linux-foundation.org, xiaoyao.li@intel.com, yilun.xu@intel.com, chao.p.peng@linux.intel.com, jarkko@kernel.org, amoorthy@google.com, dmatlack@google.com, isaku.yamahata@intel.com, mic@digikod.net, vbabka@suse.cz, vannapurve@google.com, ackerleytng@google.com, mail@maciej.szmigiero.name, david@redhat.com, michael.roth@amd.com, wei.w.wang@intel.com, liam.merwick@oracle.com, isaku.yamahata@gmail.com, kirill.shutemov@linux.intel.com, suzuki.poulose@arm.com, steven.price@arm.com, quic_eberman@quicinc.com, quic_mnalajal@quicinc.com, quic_tsoni@quicinc.com, quic_svaddagi@quicinc.com, quic_cvanscha@quicinc.com, quic_pderrin@quicinc.com, quic_pheragu@quicinc.com, catalin.marinas@arm.com, james.morse@arm.com, yuzenghui@huawei.com, oliver.upton@linux.dev, maz@kernel.org, will@kernel.org, qperret@google.com, keirf@google.com, roypat@amazon.co.uk, shuah@kernel.org, hch@infradead.org, jgg@nvidia.com, rientjes@google.com, jhubbard@nvidia.com, fvdl@google.com, hughd@google.com, peterx@redhat.com, pankaj.gupta@amd.com, ira.weiny@intel.com Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 98A24160006 X-Stat-Signature: ha7zhsc8ncxpbcbmi78qz36odp3xw6jb X-Rspam-User: X-HE-Tag: 1747229569-326382 X-HE-Meta: U2FsdGVkX1+RZ4g2oHO1iVLDe1qEEfbSTx2Ob98vtay/4hWVV1iq70xF9t5S1NB4JiFJXaZ67Q4qY1j41CUWb54bvXwvekqFpGC4ioYD+A+/KLtciihLpNnMUhm2FA1hJ4OIAQtnSy2AA7jCWDI7oLoXf4GXF5iRXuCVEs8BzYkSq+1M6GJr+rjnMb3SyPOAzLdQ6fdAcNTLj4Gr7t2Kx1zxHob+2VbT9EobuC46q+cen/ninsjLgKzdjPhYAM12jhKlJXK5xD+pTGeIphSwVMkWejaXS4WLahDNMnWJ5Yxnr9hQzV0W6P7yNRpmIBMVKeCuDSdzR6UPMm5aE7SpgSYbgg7BulOocCKZ9UGT47FNh7LoMjlgfws+7IM3bhqz9k6P6SPAVahfT2etRDNwHRXGWKNPb8c3w3xpsLplQG3C7SUabyUAmo2ze5/UfiM2z+3lUxl+tXAmgvh5dJSAR2ZvEQSjUyI/mS8nTw937IwpzcrdaqKOu2DCIfYiciQ+23EgVHsyLylygu9j/y4TMH2bfRvAYuqA6jfFetsJHTN3i8vLYlSeeKKaJxcO9ZGRhRqZoSqn5MWHwhBTtIR6nRxLLtsPRm4ngzm7s+pENHypd/PsmKPHWXwwd829/xKqAneDvsNHyz3PatmPi2QfjbhJAkOQTNHVnTZkFTPDAX4Q/hVRrcTRuApCVlqK4j4dwYUK0R0F+Lc1x73UPanbXhhfQWpy+f4azQyyr0RbFa5tXDFSoQISewP7zf1j+6olV3JoT2MQi2rZpDqDWyniBmjD8F/I012Xn17UcvvJ7rKNZSIBGxAl9HC0qdH2bv8A5wB/OH3bbrJarB2W6u6WW6e5eWGQ1OpIYBBQofKeiEthLapbX1GKmyIksdgYcs3WCbnQxZgR0w4XN0teh3oVwLRK8KrcLgE4rD2r4TBL7ri/8ZB2SzB91QfPHAKcvmUPLm/sDxSlQIqfR2oBCiy PYJdCXXG wAfrJFc4BsK6sPntnKXXl19qPvnckKvsuoTnxdr6PygJvmO+TP1MHk5j0yokyzSCwydyh8J0ACBmz84EltQHw7szDchV9CD8MqSBokOdOWbt3R7Laflfg0gURBhGAbhFkhRGUW9USS8Y/oQSk3X+bDfdL9Dvp+BPb1NEhEaw22+Ybu4qNjWem7SCb3fuLo7H1qAFORaz5uCmJ04gmuhjd6NLHme39blpzFERp5BCVWBGLE9mm4DLZDKzxkpN/xNfmJ6z/CaxzVroVHLujmD10+h/5zDOVEuXjkYXQpGPMQTKteTYpQjV0uO7K7d7Niye+8+az6pscDv8zRyVzmIpoVrzY+O5DW3yUGtSdQ0iSow2+apb3r1SOTucuTtWDztUdta5kh7MSF7ykNxf9F6kpJrLG51yflNI4g9F5FcqKDohwuFUzYUzglvmgYHAPCCZw0P82FanPkdcL/kA8AU0Y3B9J/enuaoTBrvWCG0WW8vYpE6SMfyHJUPqR0aROwvtmdcM1+drQncygVjlRh3f7qOgEzTSHgs8JnAGy0cHzMx/mrVrd3nC0Wnm8k9l/uLgCrQKZywJ8pOTw9Z08JVMIoj9+RYssV8rkcQ5pLXTCbPNt/rEHXPY+j5v8cZlN8Wx8CvER9u2dxsRgjAJcCU1lKTYQ40/52qtMDLlL3fx6AeZssf6Skj3Jktw+yMEwVC0CrYLC 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 Wed, May 14, 2025, Fuad Tabba wrote: > On Tue, 13 May 2025 at 21:31, James Houghton wrot= e: > > > > On Tue, May 13, 2025 at 9:34=E2=80=AFAM Fuad Tabba w= rote: > > > diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c > > > index 8e6d1866b55e..2f499021df66 100644 > > > --- a/virt/kvm/guest_memfd.c > > > +++ b/virt/kvm/guest_memfd.c > > > @@ -556,6 +556,32 @@ int kvm_gmem_create(struct kvm *kvm, struct kvm_= create_guest_memfd *args) > > > return __kvm_gmem_create(kvm, size, flags); > > > } > > > > > > +static bool kvm_gmem_is_same_range(struct kvm *kvm, > > > + struct kvm_memory_slot *slot, > > > + struct file *file, loff_t offset) > > > +{ > > > + struct mm_struct *mm =3D kvm->mm; > > > + loff_t userspace_addr_offset; > > > + struct vm_area_struct *vma; > > > + bool ret =3D false; > > > + > > > + mmap_read_lock(mm); > > > + > > > + vma =3D vma_lookup(mm, slot->userspace_addr); > > > + if (!vma) > > > + goto out; > > > + > > > + if (vma->vm_file !=3D file) > > > + goto out; > > > + > > > + userspace_addr_offset =3D slot->userspace_addr - vma->vm_star= t; > > > + ret =3D userspace_addr_offset + (vma->vm_pgoff << PAGE_SHIFT)= =3D=3D offset; > > > +out: > > > + mmap_read_unlock(mm); > > > + > > > + return ret; > > > +} > > > + > > > int kvm_gmem_bind(struct kvm *kvm, struct kvm_memory_slot *slot, > > > unsigned int fd, loff_t offset) > > > { > > > @@ -585,9 +611,14 @@ int kvm_gmem_bind(struct kvm *kvm, struct kvm_me= mory_slot *slot, > > > offset + size > i_size_read(inode)) > > > goto err; > > > > > > - if (kvm_gmem_supports_shared(inode) && > > > - !kvm_arch_vm_supports_gmem_shared_mem(kvm)) > > > - goto err; > > > + if (kvm_gmem_supports_shared(inode)) { > > > + if (!kvm_arch_vm_supports_gmem_shared_mem(kvm)) > > > + goto err; > > > + > > > + if (slot->userspace_addr && > > > + !kvm_gmem_is_same_range(kvm, slot, file, offset)) > > > + goto err; > > > > This is very nit-picky, but I would rather this not be -EINVAL, maybe > > -EIO instead? Or maybe a pr_warn_once() and let the call proceed? Or just omit the check entirely. The check isn't binding (ba-dump, ching!)= , because the mapping/VMA can change the instant mmap_read_unlock() is called= . > > The userspace_addr we got isn't invalid per se, we're just trying to > > give a hint to the user that their VMAs (or the userspace address they > > gave us) are messed up. I don't really like lumping this in with truly > > invalid arguments. >=20 > I don't mind changing the return error, but I don't think that we > should have a kernel warning (pr_warn_once) for something userspace > can trigger. This isn't a WARN, e.g. won't trip panic_on_warn. In practice, it's not meaningfully different than pr_info(). That said, I agree that printing an= ything is a bad approach. > It's not an IO error either. I think that this is an invalid argument > (EINVAL). I agree with James, this isn't an invalid argument. Having the validity of= an input hinge on the ordering between a KVM ioctl() and mmap() is quite odd. = I know KVM arm64 does exactly this for KVM_SET_USER_MEMORY_REGION{,2}, but I = don't love the semantics. And unlike that scenario, where e.g. MTE tags are veri= fied again at fault-time, KVM won't re-check the VMA when accessing guest memory= via the userspace mapping, e.g. through uaccess. Unless I'm forgetting something, I'm leaning toward omitting the check enti= rely. > That said, other than opposing the idea of pr_warn, I am happy to change = it.