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 403F8C52D7F for ; Thu, 15 Aug 2024 22:10:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8E10F6B0269; Thu, 15 Aug 2024 18:10:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 892006B026A; Thu, 15 Aug 2024 18:10:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 759FB6B026B; Thu, 15 Aug 2024 18:10:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 52A556B0269 for ; Thu, 15 Aug 2024 18:10:42 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D2E7EA113D for ; Thu, 15 Aug 2024 22:10:41 +0000 (UTC) X-FDA: 82455875082.01.1D5D3BD Received: from mail-oa1-f45.google.com (mail-oa1-f45.google.com [209.85.160.45]) by imf11.hostedemail.com (Postfix) with ESMTP id F1F4840014 for ; Thu, 15 Aug 2024 22:10:39 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=dYw2p283; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf11.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.45 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1723759780; a=rsa-sha256; cv=none; b=0i5WWjwqLJH58aCUyOqxNG+zD0rn+eHXyd2ifV6O7CEkJBdj86HhqrBeG4Y89Mmeuy3Jnf s53xDFRt2wYVcpndVUrOsnZnAGjP+XezHJcKPZg9/cs36kZIcTay1Fxud0ZcxSmEXXDKmd pKKm1483eeQeJF7C61aShzCHcObDfhM= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=dYw2p283; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf11.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.45 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1723759780; 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=T/7nC3aPz88eLKXfHY4nGDT403RKERjytoDOA8SZsNk=; b=0nHxSumAKOK1pXkF41jLsC+eGVPRunbol4GD1e5PeaZ9HkLyxCRUPXs2ZEj9FjVVecaLO6 OVANfNO48kpPqAABetI39MkUH5L6Z0L7JAj0KVj5ZBS7hv/9GzyrfmlDgrmByjoHh0thAE EDmyGvOY+pVw9lqY519b+6GmjDn7duk= Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-26ff1dc94f8so847497fac.2 for ; Thu, 15 Aug 2024 15:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1723759839; x=1724364639; 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=T/7nC3aPz88eLKXfHY4nGDT403RKERjytoDOA8SZsNk=; b=dYw2p283pwD8Q0WAP8jDoRv0aqMxUviQHMdcsy3T0mNuU9Fblgr2kjjgL7FMaL/1RR qgF9A/mLNhdwrZLzIb7QKgEZwlMPrnol5qEf7U886rQYaaElFIjx8eA7aqSXbh4k2i2L S6R8cJyzY/Lt0UTnDD6f0O7IY8RVhVvIsnCg0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723759839; x=1724364639; 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=T/7nC3aPz88eLKXfHY4nGDT403RKERjytoDOA8SZsNk=; b=vGJeHz+fU/yzOiKQu39R5NIXh6LhHlichQWi2ltI1AkyTXIty8LNKcSiU6Tm8gkiAI GGDtIZg7crwKFSf4fwvm9b6nT8XFUH6x8VFz0zW7f/tmJkl+vAvWydfWSn3QIQ4pPSeA cKm5sVgwuvd2xLHHkwIwJkILFeqkqIeNKDfazWuHGYRv0ZWlbtJKl8wxrWuoJNbYUjRO Zw2B2eHGDq1pBH9xz7Ck0YeBkoA3NV+YTDMEPGS/3ewrah3I6xIo8sIjxX8n6TLfuvIM qZPqK3KZCssHgToi8QeXQiPfPzkth7y8VCu5pPWy9dHjSGtIGv+GczntQ9b4u30w0MCW 0hqg== X-Forwarded-Encrypted: i=1; AJvYcCVhvqzvre0m8u3QY4NbEyAB6ol/O60hhjlkwchLW83+hwt+heKMnJpO1LttBbxROWCbsFgbGMfYGey+TIPPkaeNv9s= X-Gm-Message-State: AOJu0YwzqNVRKOXPtwQWiEaJCfX2h/BELiMNqO1ul4NEbFb7pdgrUURO LgrUIsF4Qh42OBMLnl+il8Hce9svijwp3fKCw+av0DGqfxuxMQFxXGL0PI3iOOgl61zg80JpdUm QlEXCtQSzQ2TqQF9FxhFQ7Kr+BXqzpBv/j3Qa X-Google-Smtp-Source: AGHT+IF5LJMV2jdY4Pyo/ZU+/INrJJp5kECqy7go8Kj+jdNivGAtJJE9PKTXPviz151/f4Pj9/aSiWwI85MX98NspuE= X-Received: by 2002:a05:6870:961f:b0:261:87:fe1f with SMTP id 586e51a60fabf-2701c566835mr1108430fac.44.1723759838875; Thu, 15 Aug 2024 15:10:38 -0700 (PDT) MIME-Version: 1.0 References: <20240807211309.2729719-1-pedro.falcato@gmail.com> <20240808161226.b853642c0ecf530b5cef2ecc@linux-foundation.org> In-Reply-To: From: Jeff Xu Date: Thu, 15 Aug 2024 15:10:26 -0700 Message-ID: Subject: Re: [PATCH v2 0/6] mm: Optimize mseal checks To: Jeff Xu Cc: Pedro Falcato , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, oliver.sang@intel.com, torvalds@linux-foundation.org, Michael Ellerman Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: F1F4840014 X-Stat-Signature: e15tesp9e74xfxdj8x3dkxjy3y8xbyqm X-Rspam-User: X-HE-Tag: 1723759839-653731 X-HE-Meta: U2FsdGVkX195lGdmmd9ZNDxmXtQi8N86xqCUxlKQlijx+z1OZ6c4h0t16o5r7/onlxoATp0f/k5NjDbd+9UNmYp73yhZ12eHZvpzpjWmlgE5MqcbfxDSl8psTwE2P8IQ/jSPtZUnfx23fjSezu1YtdpmPACZhwcHQeNpwp/3XRyWXuoGYoTahvh7G7RQc7eOzExgbfNOPtMejrm6nWTevx/t5RtFXFK8GRVafER3gZ4KUrnV/GqcJHV3WGRQJ5no3D7MzmK/EYJ4bUhlmlbMOCvr6FADW3MONBsFVGqVBzsc8RyJF5il+ZNBzleTrgIfUyrPGJghI/nzyiFuVPOV13xkm1tZsVw4iqg3Snjn9weGXR3wBOcsJhjBf9LJPi752XPrX/9kuVMU+AUEJxGgpLz21HMlUqGQS8eXm9YxzNOfdiv6DEyjHFbMt3KZN5ybBjQ9HkmuiNgcL1irfuK7QaurDJZuxaHrFkv2sAjsUbBBIz4oABvycGswZbJJRgNJSAtHwOuhHqD7v3SzLZ3GyE9WMqUVFzTIWIR0h7nnMaeeGJ5/vdc279E7ZM8HsU00oGHCHcZdC+OhAofesZ287AkPBfaatXeyRD0LujoVRfS/zTXTMvjW3QDEHgYan29KiijB4I1W532gepNvgyYxZbVOe1QpWx9IfM7lF1bghL/FYImkihnMX1GT4dBr9WvbOEf9z8eS6fmpB9i5Nu7vjgebPa8SwZeZcsRrQ6KpWejYoo8smwmIejWxlQF7GCR4omaRnQMkERBtWzeq0G12GM0EjWT3dAS3yMzcUQmbjfr/txva4hU3COf9JJDGW0fZgHukzYLo8FGMdqoXSltsLWzyUtxCPG/M0uHGEaZZG9dNL7o7uLl0XCNvq5DAvXWoXDmtmaR5jBfJYve8LHM9d/oZeBRcEIOTvFYsuiIbTH0TCFktjHfIPkxR2MvWP2wJKTL3nwsoVX7s3HCnryg go6+qj2p u6zxw70R0rL43bQAmin/xnv4mr9/qoDp2e3K9ul4PMn0uyGobywDH5kWG4h/PtSlQsRJAKU4ZnHccaTjBHeRYOQJeB8eMRjHhiBmL7+kyXhB9+3UxcK2igKe3G5mLa4fJXwf62vJvadCm2ige2Y11sGf8++2GrygrqTtrle4dOKgGWaX3R8e7KobYQmvLKQ2bLwgFB8EwvUSWEg86ynpFCjlHQwgHKE+x3D3CwLzwdhQUf4RfKNLnkZI/vD/DAdZgqEVgUB/Ss1uh3iVrKc8GYeoJhuPub2cRY2Lcizv7ARYMWsbKGgH8VAtJgkKLxHQ69ON0IS5tU0diLv8KOTq29R/y7WJghL8DoLsTP+AlH/+joI4jBwSEqh0x7ovBvpoUYwHB3ugjJWMie+Q4CTe45hmuaOzfZaDQkp+lckhpfjij1Oc0V2ody6e01E/GU8ygHA+cghPceZZ6gUT5h93IBxM5Ag== 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: Hi Andrew, Pedro On Thu, Aug 8, 2024 at 6:03=E2=80=AFPM Jeff Xu wrote: > > On Thu, Aug 8, 2024 at 5:34=E2=80=AFPM Pedro Falcato wrote: > > > > On Fri, Aug 9, 2024 at 12:12=E2=80=AFAM Andrew Morton wrote: > > > > > > On Wed, 7 Aug 2024 22:13:03 +0100 Pedro Falcato wrote: > > > > > > > This series also depends on (and will eventually very slightly conf= lict with) > > > > the powerpc series that removes arch_unmap[2]. > > > > > > That's awkward. Please describe the dependency? > > > > One of the transformations done in this patch series (patch 2) assumes > > that arch_unmap either doesn't exist or does nothing. > > PPC is the only architecture with an arch_unmap implementation, and > > through the series I linked they're going to make it work via > > ->close(). > > > > What's the easiest way to deal with this? Can the PPC series go > > through the mm tree? > > > This patch can't be merged until arch_unmap() is all removed (ppc change) > > Also I'm still doing a test/reviewing for this patch, perhaps it is > better to wait till my test is done. > Sorry that I'm late for updating this thread. With removing arch_unmap() change landed , there is no dependency for the patch. However: I have other comments: 1. Testing Testing is 90% of work when I modify kernel code and send a patch. So I'm a little disappointed that this patch doesn't have any test updates or add new tests. Which makes me less confident about the regression risk on mseal itself, i.e. a sealed mapping being overwritten by mprotect/mmap/mremap/munmap. I have posted the comment in [1], and I would like to repeat it to stress my point. The V2 series doesn't have selftest change which indicates lack of testing. The out-of-loop check is positioned nearer to the API entry point and separated from internal business logic, thereby minimizing the testing requirements. However, as we move the sealing check further inward and intertwine it with business logic, greater test coverage becomes necessary to ensure the correctness of sealing is preserved. Yes. I promised to run some tests, which I did, with the existing self test (that passed), also I added more tests in the mremap selftest. However I'm bound by the time that I can spend on this (my other duties and deliverables), I can't test it as much as I like to for in-loop change (in a time frame demanded by a dev in this ml). Because this patch is not getting tested as it should be, my confidence for the V2 patch is low . 2 perf testing stress-ng is not stable in my test with Chromebook, and I'm requesting Oliver to take more samples [2] . This due diligence assures that this patch accurately fulfills its purpose. The in-loop approach adds complexity to the code, i.e. future dev is harder to understand the sealing logic. Additionally, it sacrifices a security feature that makes it harder for an attacker to modify mapping (currently if an attacker uses munmap with a large address range, if one of the addresses is sealed, the entire range is not modified. In the in-loop approach, memory will be unmapped till it hits the sealed memory). Therefore, I would like to ascertain the gain. 3 mremap refactor work. I posted mremap refactor work [3] , which is aligned with the direction that we want to do in-loop change, and it also (imo) a better version of handling error cases for mremap across multiple vma boundaries. That patch set can be applied on its own, and the test cases added also enhance the existing selftest. I hope my patch can be reviewed, and if passing perf test/approved, applied to mm first. Thanks Best regards, -Jeff [1] https://lore.kernel.org/linux-mm/20240814071424.2655666-2-jeffxu@chromi= um.org/ [2] https://lore.kernel.org/linux-mm/CABi2SkXtZLojx3AQU4C=3D41NtBPGjVB2+fv_= KWziOqyXRQ8P7Bg@mail.gmail.com/ [3] https://lore.kernel.org/linux-mm/20240814071424.2655666-1-jeffxu@chromi= um.org/