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 938E3C4828D for ; Mon, 5 Feb 2024 22:13:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 13C3D6B0072; Mon, 5 Feb 2024 17:13:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0CF5E6B0074; Mon, 5 Feb 2024 17:13:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7F766B0078; Mon, 5 Feb 2024 17:13:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D25F06B0072 for ; Mon, 5 Feb 2024 17:13:22 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 86AD6140902 for ; Mon, 5 Feb 2024 22:13:22 +0000 (UTC) X-FDA: 81759152244.29.B9C34BC Received: from mail-yw1-f175.google.com (mail-yw1-f175.google.com [209.85.128.175]) by imf23.hostedemail.com (Postfix) with ESMTP id B0CE4140015 for ; Mon, 5 Feb 2024 22:13:20 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=jLyD39wi; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1707171200; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=l+wc7Sgfr0FX1NUK9lSF8NbngE4sfyd8aYAoXi3MmuY=; b=AVPwQdFSIQW6NQ6wettAAcMfZM42qTrRjJUqFsrPlxJWyhtg+f672AuF8KDQ57n2qrMW3o VcubrpMqCV0o1vtjxKjdpKgL96rG54WAX0KItnhO2npxXniQ6ai/5nyRbx23Y+p7mK1jLu 5GAuQ78srjgRVWaN+8weix9MDCseDFU= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=jLyD39wi; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of surenb@google.com designates 209.85.128.175 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1707171200; a=rsa-sha256; cv=none; b=bJl/JZ5wfKjnvGqnHAPxEY7j+JEkElHT8i1keZJqJl71zjPtglFcpAug4tS6PG+7isYpoa wCxzaErKwqHv42f/ORQhPY11XgEVz/KZzsGBH7Gt9/t4oThJM4pqGsBWYQ9gMetkjXChFt UFYjte/hxYmwt3SAkIBY8UutTxh2V3E= Received: by mail-yw1-f175.google.com with SMTP id 00721157ae682-5ffdf06e009so43471087b3.3 for ; Mon, 05 Feb 2024 14:13:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1707171200; x=1707776000; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=l+wc7Sgfr0FX1NUK9lSF8NbngE4sfyd8aYAoXi3MmuY=; b=jLyD39wiCrWQQIqM++xnW3s/nLcGLyV9GoCrM7PMsdrkCiSeQGXeL9L9GQrRdZV9zP nca9KXQ6w9Uxi6Q/aoPCK7lZLcaKpbaHe2jSeOMqoNgQ3KeT10N3ff2a9SK8XFFQrZHM vVmcluxBlSmgCEGq2Kul9FbvWWMD+iq1Cj4MPBHP1wCNRgzzMkJHGdLYE98s5rDCNxb9 aGPaM7CWDnpM0PpJiAIpiZ1yGiehw6PlsX2tlrSaT423Fc/n65LD+BA2Z4EuOM0HAbcm rNAFCTBxVFyZarQD3viU8D0/uI9J6ZTck4xhar5wMfBtJIwiIzcUJcCx8nCj7C5elOv/ vKZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707171200; x=1707776000; h=content-transfer-encoding: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=l+wc7Sgfr0FX1NUK9lSF8NbngE4sfyd8aYAoXi3MmuY=; b=KGhsUerKuCRW2iXIdNkm+G04Y4PWj2Nme2gNiD5+HORQy2eugdyDwysyXIss1wfj29 bIUMUulI4GYotIxbuZ4NnqBUVRTea/zhAVkQy5CT/Dk71NmLhNVEbHDvtReFVgMkLr+P 5/rQsRyGVHZs+b6oGZBhPHZaK/e0/ThKgaGJgvf43MwWJsHWYL+KFGTr+bI3VfO6Sazn 1QXyz07f6q/Kv8xtGw29LqwIEPFm7SIqnLi2PW6o9/YCegJkq03rXM8t+TWNLIa5WBHw eOdTDYBBS2a0VEEzjjZzy/Cz8jZptZwJa2zGM8ur3cuNWoJXfsSHPuXc0Spmjx+qzVcP lNLQ== X-Gm-Message-State: AOJu0YzjiSI8qLK/UmePp9CYNvjbNVTbdALcl3ho43pPaXsE0hnwWEhE VHRp/VJAiAT2wbnG9vjeitnKi6YTvfOxVTBQKkzZ07x/DyibfV/i2ueqeLHXZDQupWoj5uDdmIL B6Mhg2BfhBkJgja6Xyp8AR3krY5HrG/ZZboOd X-Google-Smtp-Source: AGHT+IE3Q8rQ7p44qPRhpPecrcgKN57uf9gFqW1Q2sgeAXqYfYu/n/QNxOLHPNun1c2+nnvHUGp3OOQurFj1SVrbBZ0= X-Received: by 2002:a81:b715:0:b0:604:ea3:6525 with SMTP id v21-20020a81b715000000b006040ea36525mr1064920ywh.0.1707171199364; Mon, 05 Feb 2024 14:13:19 -0800 (PST) MIME-Version: 1.0 References: <20240201204512.ht3e33yj77kkxi4q@revolver> <20240202151345.kj4nhb5uog4aknsp@revolver> <20240202192137.6lupguvhtdt72rbr@revolver> <85714.1706902336@cvs.openbsd.org> <20240202211807.6sca4ppezma7cyev@revolver> <20240203044534.wkyfkxdlnskxctsq@revolver> In-Reply-To: <20240203044534.wkyfkxdlnskxctsq@revolver> From: Suren Baghdasaryan Date: Mon, 5 Feb 2024 14:13:08 -0800 Message-ID: Subject: Re: [PATCH v8 0/4] Introduce mseal To: "Liam R. Howlett" , Linus Torvalds , Jeff Xu , Jeff Xu , Jonathan Corbet , akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.org, usama.anjum@collabora.com, rdunlap@infradead.org, jorgelo@chromium.org, groeck@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, pedro.falcato@gmail.com, dave.hansen@intel.com, linux-hardening@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B0CE4140015 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: hk6hirhy6tg5dkwic8wijp8m6x1yqyzm X-HE-Tag: 1707171200-520455 X-HE-Meta: U2FsdGVkX198eV/1saJTPofwF9iwA2Zg+L0qKj90Q/6cyJkfmrbRr233Xa7kCKaUJ7L92n6fnn5qDE3tBsuxOFIEOumLd93C9TzGcrHdbqHzYHjHDbfHQczMTsfuXv5Eujk54zCtk3Ge2p4zd4wbItd4wc3a7bSUL3Ly/AinMkm+9jAy70PxJNBCgQX0NXvdNAxVzs8aue5qWrYu+NpNwDcirRoZnrqtcxweNZ2HIe+sOaw2U3xhry0ikOV4KPgizO6tscC7muM3tpgDBgNfRZOJi44cuOejx7WHNW7Wir/gtFhMvjifeg8+kFwYykAZTeH30kCbOf9S7Xk8HWo70HqqtIKjoxrFD5tHjyAqvrUbZM2SWtzf2Du/FhL8TYqabx+SQKfrIKaqj7z5vlKipOcSwOcVWq4yrFAa3WsTfV1OOtJ1ApIT/8JV3l7tdy3EfNZ4AGRzSPGYhIiBzk2ngSsfzlxS1rUjaQkSDOjNR0Wj9w6T/1iU9gG6VuW/PWWZJNFVPrhAyLKysVD5+QYCzEB5MJ/R+vn+sWddrrL4d3xMORcK8CXhX2GOMg27f9OkruBD91vK532ZjCGSPPdZE9+5afrzTcFL/Pqxb14HbB4HgM2Jw44bor2GDlV6wDF4EsY6sPQY7BAvG6/zDgo0fnncHbK/f6XcwJH1iZitgLx/UETcOsq+8IhveaHiofkV6tRI2QeFJBc1sh0IopVpxJMMhFYcvNT37vHxBc73IHedccVczoWG7ghnDAu61V3C2hVDOBSQFCGRMIFp8iwILU+Q+PJHA/7+RwrlYxw1w4tpk5SNcwA9IKx7apdrVzsLobg/tRNVLzX0WdskgeOmfVdUYvfYqU9bAypGjRbK8eEqVd56dz9HzKJ8M/YmPjJgNUrNJsgE7RSR92A4+hNCjPHNzBQJ8CenWEn+B+ETmS9PZ7xm3cEcqxtkOFA9kW3TSfbqqWUMk4OTtACtnEQ 5Cu7Oph/ vJ+VLyuQZnfnQIvde1yIGacYcTVSgC4yJhX4PJN2iFBhBMbZapEz2cSayqeTNfwSHwZj9yqyJRUiqUPxo3J0E0JpxgWYkfd1vv4QGkbfObyI3hgWEyZxczPxkttOAQqdrFcCugo76qL89SAqjP7BF4dHW0GHIm74L5J/6WbMEILZEFS0MA4VYNlYy0+X3UDE/cSPEiy4Au34jB7E+2ceQ+DymNLIPuWmfbSG5MP3tNmemazSGGE5jyOBndzEpdAY0LhpXejTFQx8TZK5NkC3Ig+llFNgXBb5QsqCW9c2M1yAWwFNBu0dCq4WyZC5t9hek7eIaL8duob9qgbsmo4h9lSa5XYG7uSSoi3br4EC8LrCKTJTGqhLHhM8Oqsm66M04IFHy 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 Fri, Feb 2, 2024 at 8:46=E2=80=AFPM Liam R. Howlett wrote: > > * Linus Torvalds [240202 18:36]: > > On Fri, 2 Feb 2024 at 13:18, Liam R. Howlett = wrote: > > > > > > There will be a larger performance cost to checking up front without > > > allowing the partial completion. > > > > I suspect that for mseal(), the only half-way common case will be > > sealing an area that is entirely contained within one vma. > > Agreed. > > > > > So the cost will be the vma splitting (if it's not the whole vma), and > > very unlikely to be any kind of "walk the vma's to check that they can > > all be sealed" loop up-front. > > That's the cost of calling mseal(), and I think that will be totally > reasonable. > > I'm more concerned with the other calls that do affect more than one vma > that will now have to ensure there is not an mseal'ed vma among the > affected area. > > As you pointed out, we don't do atomic updates and so we have to add a > loop at the beginning to check this new special case, which is what this > patch set does today. That means we're going to be looping through > twice for any call that could fail if one is mseal'ed. This includes > munmap() and mprotect(). > > The impact will vary based on how many vma's are handled. I'd like some > numbers on this so we can see if it is a concern, which Jeff has agreed > to provide in the future - Thank you, Jeff. Yes please. The additional walk Liam points to seems to be happening even if we don't use mseal at all. Android apps often create thousands of VMAs, so a small regression to a syscall like mprotect might cause a very visible regression to app launch times (one of the key metrics for Android). Having performance impact numbers here would be very helpful. > > It also means we're modifying the behaviour of those calls so they could > fail before anything changes (regardless of where the failure would > occur), and we could still fail later when another aspect of a vma would > cause a failure as we do today. We are paying the price for a more > atomic update, but we aren't trying very hard to be atomic with our > updates - we don't have many (virtually no) vma checks before > modifications start. > > For instance, we could move the mprotect check for map_deny_write_exec() > to the pre-update loop to make it more atomic in nature. This one seems > somewhat related to mseal, so it would be better if they were both > checked atomic(ish) together. Although, I wonder if the user visible > changes would be acceptable and worth the risk. > > We will have two classes of updates to vma's: the more atomic view and > the legacy view. The question of what happens when the two mix, or > where a specific check should go will get (more) confusing. > > Thanks, > Liam >