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 A589AECE577 for ; Sun, 8 Sep 2024 21:35:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0CBF66B00A7; Sun, 8 Sep 2024 17:35:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0545D6B00AA; Sun, 8 Sep 2024 17:35:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E10066B00E1; Sun, 8 Sep 2024 17:35:58 -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 BE3F66B00A7 for ; Sun, 8 Sep 2024 17:35:58 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7391B16076E for ; Sun, 8 Sep 2024 21:35:58 +0000 (UTC) X-FDA: 82542878796.05.77F9D74 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) by imf29.hostedemail.com (Postfix) with ESMTP id 8B9B9120015 for ; Sun, 8 Sep 2024 21:35:55 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GGcK8m1p; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.128.42 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725831273; a=rsa-sha256; cv=none; b=sFLYq2ty/lNlvAQ6rFoAQwDn4PmyZutx8ukkKdLokzPqIVQC9CPRzKJpjyrgp9vFxzOAEz 4QllIBVLh/rSJWLvathpp8TdCDcD4lQVTvc12Jf1rZsaC14kWc0nfk6iaXEZucP0BmOngf vAfb4FnNVg/83No022ipSYA9yYAEECs= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GGcK8m1p; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf29.hostedemail.com: domain of pedro.falcato@gmail.com designates 209.85.128.42 as permitted sender) smtp.mailfrom=pedro.falcato@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725831273; 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=ebxD+tZxKc5DCOdCTQdYFhvzT6rv4DDDxFg4BZPdZes=; b=Sc42zFq/pBxaksscea6ECm1n3nx8Q0ZKvwp52AYgzf+FYWuFfesnX9PhcKGeEEPU/bAaV1 V/ptAkXYKg1beKIadlwil/fnqJpciBj57w/DHfa582ryO+4ixFS8s/SRPqlPuDrwBf51vO PlPu3rTmKAEfKveh5WmCv314WYj72GI= Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-42cae4eb026so13622435e9.0 for ; Sun, 08 Sep 2024 14:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725831354; x=1726436154; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=ebxD+tZxKc5DCOdCTQdYFhvzT6rv4DDDxFg4BZPdZes=; b=GGcK8m1pDxUZhYUGma0/8rs3Hl5MN6mWGOTsnAqLv4Sp1ghFiAohyV0hgO6KwWOq6E lu+gLlHKGSR2KkxkTan09QJlXifwN4PjoR57Q6Gt0EXUEvltuPHIjL7rljymRPTfy/B3 lYYStq871DrGWgH7ih5wqafr8yhqPWuMlf3zBUTAisxWaxPBX3VswhvzcmHDPhGX+kQq Ncsf+CQCNtIeKZT82dtgandp8gheUaTBuPatgDynXPujHow5UkpODgv+3uDzrQObEFeV t/eSr/1EigBNR+ur20DsX4yl/mytrUTfhDxx0/sI2M2bf/KyLU73kZSGhGn/0F26l1I3 hguQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725831354; x=1726436154; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ebxD+tZxKc5DCOdCTQdYFhvzT6rv4DDDxFg4BZPdZes=; b=j73sVGPpqc2yV9Gfo1SBqmeR8v0A56QIcO6mQtn3bhPI+LWruO/xQ/XYq4VwXA2XKL GFUxkeTk53fPLXPDP2ucumprnxZvg6N8NQti49pO6MTqb0KPzwsO78yglQeA8+PCBiHs ZxAVRVmBDg/tNOYv6aqrBMR2wrwLDQm1Wkw8KN/rIcH6hk5hA4MhNJu6AsTlLEpIdha9 UKmwoTZ8X3dHuHWkuEdKUoZFJnQ3V6SmagHT8lLxpvE1H61YybRY65MKIgSEv3RC5lhM Z0g1HcU79dnZIWApKrdXZ7wF05+udwlL6AnQYwbE7UwAikyl2VtrpN/3lBQPVUbRfvDA ZaDQ== X-Forwarded-Encrypted: i=1; AJvYcCXfIpcICYdMMIV/6cOYO9aW4A2+Pl9eerBhVZDxEUMuVNxZXv4vPrXB2jdLX1nPyeSpUKJsNyvq2w==@kvack.org X-Gm-Message-State: AOJu0Yy3P18frSx/O7o+mwoinednvShR5YPx9ERz3Zp7D8wUkg021GJU F1GOEtE11SrKEuee/HaWD6uTfRuaOTd0C84HJFKEs2TDL0DMiHjg X-Google-Smtp-Source: AGHT+IEpX/kMHwkTt5gQUGai6vWC2fUNaDyAAgimr1BCXN9cj+uj5X3JVt+PwrdiJYnf3s8A5mQQAQ== X-Received: by 2002:a05:600c:3483:b0:42c:9999:4fb3 with SMTP id 5b1f17b1804b1-42c9f9d7d6bmr67647945e9.34.1725831352969; Sun, 08 Sep 2024 14:35:52 -0700 (PDT) Received: from PC-PEDRO-ARCH ([2001:818:e92f:6400:96b:aa92:afc0:2d3d]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42ca8cebd35sm72122655e9.0.2024.09.08.14.35.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 Sep 2024 14:35:52 -0700 (PDT) Date: Sun, 8 Sep 2024 22:35:50 +0100 From: Pedro Falcato To: Lorenzo Stoakes Cc: Jeff Xu , akpm@linux-foundation.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, willy@infradead.org, broonie@kernel.org, vbabka@suse.cz, Liam.Howlett@oracle.com, rientjes@google.com, keescook@chromium.org Subject: Re: [PATCH v3 4/5] selftests/mseal: add more tests for mmap Message-ID: References: <20240830180237.1220027-1-jeffxu@chromium.org> <20240830180237.1220027-5-jeffxu@chromium.org> <4944ce41-9fe1-4e22-8967-f6bd7eafae3f@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4944ce41-9fe1-4e22-8967-f6bd7eafae3f@lucifer.local> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 8B9B9120015 X-Stat-Signature: wipqp345h5row4ctayykze8x1mefmnuh X-Rspam-User: X-HE-Tag: 1725831355-41171 X-HE-Meta: U2FsdGVkX18B2hxJ0t5XPyxZpmXuOLfviTiN7cxfuhkijHasCeJM98H1DrSaWPss8djaY2GvGSxmf0a4ey5qpzaG4P3ZuWRKIWo+8EXxa7lR6fEloldqNKPKPdtyi27+/UAmSYM0SPJKuQrawOmvVSyu0afTlKxY48TcwWJPJqUQAZhIxmmoOjzkcT4Abolu0ZMnezVUqswLdtXNewbkh5oVfdEYV5xJqoX1+GUq32GiuFksDJDF/TmCW6XHBnLdSQ+DedKn7hWu+sNEbRsD8YNQExfUGLvotqJUyJlsANuKy/3R1HV5yiBb+xkWssAIaYk2X6q+K4lmRQz2GZjE8/5BFvVRZQlx0OB5bJV2CtAA59z0pXO6fyBgqPfWYvmgOpNv1EaIu41TGBCkzVCatWtyXjpyOFY2j75ZQ4m2VrY1sZSzHqTMjK+ZVZgVu/a0PpstyDg3ZMuise9YFxGix+B8LctoQ9c5l8/OtmXVg/M56qV1oaVLIqDu+H5WBEiP0Lf84pDE9TC0OeLPHM15hUL3dYIMV4KoIZ6MaP5LiuYtArX/fci/ZTlW9+UVr+FqTFYMK1peSFuT6pmjtVTWeOvKlzYEdIA4JEz4jvxdmK74rAS3yTcDe77BWqV4EBLxVbSGb8YHt+4JggueQFazGZMOGA4W0mrQ4zX3OjNLLom929MyYEu9KFdddoB6pwFop8Opwdfkf9y7NnFK8Bl8kZGLl9HpxHwFCC/uOiInHPo7ql5Avfxg8sTyA69/dQRcYklhoBHbbMkgWJrMklEYQFrBRjQ8F6i0U17mcU/eOTqfS5LXfTT0NGzMdE8vXGOMBCw9DNq8trIeLZAzFQPNVvW/ulSC5PjjGPzXerZmbTTp0did4bqzK4Lrdp1a4Gur0euY2vX2PYbe4izametmcDXUnjwkoF2/QjOP120ep1K/tD5LdSjpbPMh2szZiv++nirGVS+chYP6fnS+eam weyj673L odii7q62a6uCT3dzD0JE+8eTULHW50qttmiOozNfK7T/mLffIDDB7OOPIVHBatjovmszU38DHnMXj++kctRDTRbvbVPXO+cBBTZpgYUcKJ1/tIcYI4hC0ns/GthTqwDwWnf2EIC5d/tNgJmOzGj2ZwSHO/U2Nldba1ThwcZjX4GMdprmgn5M1u+fNGB/P0d1+iAJsG2q/TgdYQf1sHBP33Yze7gCnO3ljG9S0POwsf9x2r4NbSNJnBng+lTJQwi7ahsIyToOjy2kxp0w5GrqgZ1VUNCRgeEvg0yr49oXJyzrEixOAovSHFeXcbKX7VB5oD7zszcbhyIP9vXy1+bp0sYMdZb99y4T0WbTFcEntMrQbmXXsXrxEjQtdq5mBBLz4jtZcLjo7Zif8wejY+DHAXvZ15tjXrsxJXIOYNvawnRJJNUG3vp5/dNZbhzkG4NJuoOcnusdQNVFxcFYDW3L0vp0zs+D4DPwtAIzEQVxK8qyggryMA44g9tWNu0lETg7zQ7jstdZ/4DRueU0S4bMb76DoNu0gxMHPIqdG 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 Sat, Sep 07, 2024 at 08:27:52PM GMT, Lorenzo Stoakes wrote: > On Fri, Aug 30, 2024 at 04:57:26PM GMT, Jeff Xu wrote: > > On Fri, Aug 30, 2024 at 12:23 PM Lorenzo Stoakes > > wrote: > > > > > > On Fri, Aug 30, 2024 at 07:43:12PM GMT, Lorenzo Stoakes wrote: > > > > On Fri, Aug 30, 2024 at 06:02:36PM GMT, jeffxu@chromium.org wrote: > > > > > From: Jeff Xu > > > > > > > > > > Add sealing test to cover mmap for > > > > > Expand/shrink across sealed vmas (MAP_FIXED) > > > > > Reuse the same address in !MAP_FIXED case. > > Hi Jeff, I really want to find a constructive way forward, but you've > basically ignored more or less everything I've said here. > > I could respond again to each of your points here, but - from my point of > view - if your response to 'what is this even testing?' is to just repeat > in effect the name of the test - we will be stuck in a loop, which will be > exited with a NACK. I don't want this. > > The majority of these tests, from a VMA/mmap point of view, appear to me to > be essentially testing 'does basic mmap functionality work correctly', > which isn't testing mseal. > > Look - I appreciate your commitment to testing (see my work on mm/vma.c - I > care passionately about testing) - but we must make sure we are actually > testing what we mean to. > > So I suggest as a constructive way forward - firstly, submit a regression > test for the change Liam wrapped into his series regarding the -EPERM > thing. > > This should go in uncontroversially, I will take the time to review it and > I don't see why that shouldn't be relatively straight forward. I will drop > the concerns about things like test macros etc. for that. > > Then after that, I suggest we have a discussion about - at a higher level - > what it is you want to test. And then between me, you, Liam and Pedro - > ahead of time, list out the tests that we want, with all of us reaching > consensus. Hi, I agree with most of the points. Sitting down here to write unofficial guidelines for mseal behavior. mseal should seal regions and mark them immutable, which means their protection and contents (ish?) (not _only_ backing mapping, but also contents in general (see madvise below)) should not be changed throughout the lifetime of the address space. For the general syscall interface, this means: 1) mprotect and munmap need to be blocked on mseal regions. 1a) munmap _cannot_ tolerate partial failure, per POSIX. 2b) mmap MAP_FIXED counts as an unmap operation and also needs to be blocked and return -EPERM. 2) Most madvise calls are allowed, except for destructive operations on read-only anonymous _pages_ (MADV_DONTNEED is destructive for anon, but we also don't care about blocking these ops if we can do it manually with e.g memset) 2a) The current implementation only blocks discard on anonymous _regions_, which is slightly different. We probably do want to block these on MAP_PRIVATE file mappings, as to block stuff like madvise MADV_DONTNEED on program rodata. 2b) We take into account pkeys when doing the permission checks. 3) mremap is not allowed as we'd change the "contents" of the old region. 3a) Should mremap expansion be allowed? aka only block moving and shrinking, but allow expansion. We already informally allow expansion if e.g mmapping after it + mseal. 4) mlock and msync are allowed. 5) mseal is blocked. 6) Other miscellaneous syscalls (mbind, etc) that do not change contents in any way, are allowed. 6a) This obviously means PTEs can change as long as the contents don't. Swapping is also ok. 7) FOLL_FORCE (kernel-internal speak, more commonly seen as ptrace and /proc/self/mem from userspace) should be disallowed (?) 7a) This currently does not happen, and seems like a large hole? But disallowing this would probably severely break ptrace if the ELF sealing plans come to fruition. When we say "disallowed", we usually (apart from munmap) allow for partial failure. This means getting an -EPERM while part of the call succeeded, if we e.g mprotect a region consisting of [NORMAL VMA][SEALED VMA]. We do not want to test for this, because we do not want to paint ourselves into a corner - this is strictly "undefined behavior". The msealed regions themselves will never be touched in such cases. (we do however want to test munmap operation atomicity, but this is also kind of a munmap-related test, and might not really be something we really want in the mseal tests) Kernel-internal wise: The VMA and PTE modifications resulting from the above operations are blocked. Sealed VMAs allow splitting and merging; there was contention about the splitting issue, but it truly does not make sense to block operations unless they affect a VMA entirely, and that would also force VMA merging to be ABI ("vma_merge isn't merging these two regions and now my madvise works/doesn't work :("). Do I have everything right? Am I missing anything? -- Pedro