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 39418D30014 for ; Fri, 18 Oct 2024 14:37:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6417B6B007B; Fri, 18 Oct 2024 10:36:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5CA926B0082; Fri, 18 Oct 2024 10:36:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4443D6B0083; Fri, 18 Oct 2024 10:36:59 -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 2674D6B007B for ; Fri, 18 Oct 2024 10:36:59 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E16231A19FE for ; Fri, 18 Oct 2024 14:36:36 +0000 (UTC) X-FDA: 82686974580.26.3D23595 Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) by imf08.hostedemail.com (Postfix) with ESMTP id 2980D160005 for ; Fri, 18 Oct 2024 14:36:48 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=snopImlI; spf=pass (imf08.hostedemail.com: domain of jannh@google.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=jannh@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=1729262071; 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=pvy5eBUxdhPiiEPoS/y6D7WtkY1N7NVonPg2B7x3yac=; b=rK9tgWReO7Hgw1tA4o/V3sWOfQDq3008+yW0ZY05CMcxfxpaHC9ihhrwGBY3D1rBszYE8j JdPoUMf17P8vT04Bie417juLGJQaG5b1+KTI0Pz806a+UKE6q+m08g4I9YFBBoJhM0mU6s 7Vw8vLHFnJU82a0P/lhWstpJYj2kcDE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729262071; a=rsa-sha256; cv=none; b=s/BMUkfGlvk3rdwPl1pjCKqoiUqsQXERFKp2GLvshAUwitssvyczdxLH579UsVHBlVkpMb FyBRkX9ROAyZm2WYb+3ceYRqu8KSYTmGXkC3vnhg/koxmuA1Dtzx4UJZqajOKWvsDXkTMK bgvPLp+I3wWEshke/nYH37t96r8/OhU= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=snopImlI; spf=pass (imf08.hostedemail.com: domain of jannh@google.com designates 209.85.167.48 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-lf1-f48.google.com with SMTP id 2adb3069b0e04-539e66ba398so27776e87.0 for ; Fri, 18 Oct 2024 07:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1729262215; x=1729867015; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=pvy5eBUxdhPiiEPoS/y6D7WtkY1N7NVonPg2B7x3yac=; b=snopImlI0WbTZHJaHtf4DdzPtbxGqlY1Y7OObJWbgi1f9z0JspF0z5h2h/EKw3J4f9 g099BKwVbU7iv3RLCVTC5GmCPfHddt/CHVXu60VUTKdKI5GhQBr9zNkXTuJXY92Ezc7y sfmKBkvILdA4Pj35jiuRzHEtLSbOcv483/G4GlA1EYepoKvCjpPRBa9/RLPmLlQt7P1A TfvWTvriN56qarFkGk1VblNhuFZ87oN9iSqq/5LcBRwC6jpS8y1M4XZzDmYCZVFw82E1 jkhW/4PGPQBmxXIlUfJJuWzab4zWjY1XUligK3V5OJHIEYIMYRTE9e4rqLoeaa+xKozF xWGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729262215; x=1729867015; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pvy5eBUxdhPiiEPoS/y6D7WtkY1N7NVonPg2B7x3yac=; b=qSigdCYeETrGusBwetV4mvH9dqMzxw6iJytw5XlIl1xOxpOkYiJsPctlhZQACV7unz eovfMHYcad2qgszTSmltIXAUdhEbNX11SxRijm+ank2oGWepLDt/vhZtYsHZ1WBOx5PJ ReGjD6k1j6SvSdAzsgayt8MrHiHJsWv+bN2fgMeuCuyiEDaACef22Teq9ru1RUEBgENc 2ACjmDRHR87iXZatEzUnFH8KH/UYQKU7mCwkxeNsD1UiRqM/auLom8kOGcfkGOYQNgJr ngpMiUZNtGuJ4GvpxjzaHeLx7EBmvG95Aahp0yNeEPXwpEjpw+ZnxMr8Ln9ROuCl+uzo p1PA== X-Forwarded-Encrypted: i=1; AJvYcCUVz1J0Ed+mcQj9fNOR8DKnsQu78IjJ1bzgam4x9JpZXpPxsuEpcpdrPNd54elrEHLmt9glb+KLaA==@kvack.org X-Gm-Message-State: AOJu0YyPzNBBrOR5T3brM79WEqPlomC5ysQnTHFVx56GEN+6xyMaqPIb fRUP7Kn7UCP2hVSMfZc1ulGLSr6oE4h/Jxmuj6c3mHIZZUFq4gHjKhnImQnVXGKqBaP+6edeSKW A2AbyU/bEqMz8sJ+0bA+TZoGHodqLOXUSyZMe X-Google-Smtp-Source: AGHT+IGN5Ch4M92qnmqBGXI6V6wafb7DTaUaatifjKeXf6otrQ2Vdp/CsMIzZ88KZX2C+4NiCmQ78hfdgG1BaBCZKdU= X-Received: by 2002:a05:6512:4020:b0:530:ae18:810e with SMTP id 2adb3069b0e04-53a15761373mr323279e87.5.1729262214336; Fri, 18 Oct 2024 07:36:54 -0700 (PDT) MIME-Version: 1.0 References: <20241008165732.2603647-1-roberto.sassu@huaweicloud.com> <7358f12d852964d9209492e337d33b8880234b74.camel@huaweicloud.com> <593282dbc9f48673c8f3b8e0f28e100f34141115.camel@huaweicloud.com> <15bb94a306d3432de55c0a12f29e7ed2b5fa3ba1.camel@huaweicloud.com> In-Reply-To: From: Jann Horn Date: Fri, 18 Oct 2024 16:36:16 +0200 Message-ID: Subject: Re: [PATCH 1/3] ima: Remove inode lock To: Lorenzo Stoakes Cc: "Kirill A. Shutemov" , Roberto Sassu , Paul Moore , ebpqwerty472123@gmail.com, kirill.shutemov@linux.intel.com, zohar@linux.ibm.com, dmitry.kasatkin@gmail.com, eric.snowberg@oracle.com, jmorris@namei.org, serge@hallyn.com, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, bpf@vger.kernel.org, Roberto Sassu , linux-mm@kvack.org, akpm@linux-foundation.org, vbabka@suse.cz, linux-fsdevel@vger.kernel.org, Liam Howlett Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 2980D160005 X-Stat-Signature: snh8j5h6o1uqgxoxu4kuzxita68itrqb X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1729262208-105981 X-HE-Meta: U2FsdGVkX1/qLa9OfBOHzbpGT9ViLM26OuJPpIrfJNNpVJFZJxTnifhr23mOmNL5UUHsF5yCXZmi0ZRDKjkGGDq4zVY+84HDWQ60iNaiwzwXHjUAklCQMqSwJQa1YlAZAr/qx1Fghzm0WACiWsOH/3YXGA5uuGzDgrJNMm3G15cG9NruqYMkNG7pitZvLljDXxtWavmgY3h7oOdTCGY5UkfaUh1fKYHReWfWa7faOuRpqtt6oZ53sekI1lDA+YlQQuqmydk7T3/jEFYLxqWEowXFAeSMxdVeZpgSNtp1DRsTHaogEmU/KSLYS05kSi2J5a0/AQe8FR0/VqPnsSkK+GUV8klt1ti94xanUSU2F056eSIREbwQctiaY0Hg6/Bq9cR0xfvLDDo+V22FjRq4EwQDHKcDAlm1EI/pbNXkBVITWzkq/ZdXpaxU4VemDR0tRD2ToNTTp90AbygAGvhhTztnSjZCAEACn/HVhxIR0XxBUY22ZYY0skSdLWmmTtq2YFcPhP+t3Wo31CUCJJS1sINOWYFY6135wWx86pTBMltLFNCRepjsi04IH5W5UNtxHp3xST8fEigF5LRN4VUONKQctEmjUf9m8ShIejuVBju/Q4BBVhOIK7uZDeSGOKEr/8UTATLRggXEx8B2ykDp0dAkV1tanp5NaOyT4hqllhdrX5EOn67l9bLti0SUymENOVxVPpf7BKd11E0E2kHFuGmH8/V2of5NZyNC+ksBWGWvHsXhd8sPlZFq/wLZaxtc5THHntdTnxosISfRzoK3tUpI2Qn8iYipw0nxbOMXWnbyLrlV26PKnxEgC52Xp1Vel2zL9ocAIQt6iwICzB1KXr0rGn+zZfNt6uMArzfmqZ23hDrAIS/D+ktkdMNxZhIU02OZSu68gZobOh7cBwLOQWbxjhRHAvkCEZA7v0V14ghNK9e9cuD+TCEwDpYTRHHf/s/GBN7GwQT3786qfPJ TEGPkUiI f9i2/UTgr1vni3p5wxLmn8BkY5W0l/dkCtfv2dR/hKE3z7hzWPmsDsvxGHWPXVlQwRHjDOqffgSddQm51KCL3jG8XQqxpAHSoCa2LcrpO2EwJgCQndR4AZnWVghgE775/5gJdddF7i0pcC1f3R5eB0KUkpmopdrqV9ZHzIdMvVmigICI5+9UXsgbrQU2r31+60QeGTG6F2ucIr46uVcJ2bzBVRiVtdGXhxz9aBmIl9HwmIycHaG67jOZ13bqK9S2tCubDAn50F7tVPSaxiwqA+Hx74c1TveOw3Q9K X-Bogosity: Ham, tests=bogofilter, spamicity=0.000606, 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 Fri, Oct 18, 2024 at 1:00=E2=80=AFPM Lorenzo Stoakes wrote: > On Fri, Oct 18, 2024 at 01:49:06PM +0300, Kirill A. Shutemov wrote: > > On Fri, Oct 18, 2024 at 11:24:06AM +0200, Roberto Sassu wrote: > > > Probably it is hard, @Kirill would there be any way to safely move > > > security_mmap_file() out of the mmap_lock lock? > > > > What about something like this (untested): > > > > diff --git a/mm/mmap.c b/mm/mmap.c > > index dd4b35a25aeb..03473e77d356 100644 > > --- a/mm/mmap.c > > +++ b/mm/mmap.c > > @@ -1646,6 +1646,26 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long,= start, unsigned long, size, > > if (pgoff + (size >> PAGE_SHIFT) < pgoff) > > return ret; > > > > + if (mmap_read_lock_killable(mm)) > > + return -EINTR; > > + > > + vma =3D vma_lookup(mm, start); > > + > > + if (!vma || !(vma->vm_flags & VM_SHARED)) { > > + mmap_read_unlock(mm); > > + return -EINVAL; > > + } > > + > > + file =3D get_file(vma->vm_file); > > + > > + mmap_read_unlock(mm); > > + > > + ret =3D security_mmap_file(vma->vm_file, prot, flags); > > Accessing VMA fields without any kind of lock is... very much not advised= . > > I'm guessing you meant to say: > > ret =3D security_mmap_file(file, prot, flags); > > Here? :) > > I see the original code did this, but obviously was under an mmap lock. > > I guess given you check that the file is the same below this.... should b= e > fine? Assuming nothing can come in and invalidate the security_mmap_file(= ) > check in the mean time somehow? > > Jann any thoughts? The overall approach seems reasonable to me - it aligns this path with the other security_mmap_file() checks, which also don't happen under the lock.