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 53A45C48291 for ; Fri, 2 Feb 2024 17:24:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B13BB6B0075; Fri, 2 Feb 2024 12:24:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AC3FC6B0078; Fri, 2 Feb 2024 12:24:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B2C76B007B; Fri, 2 Feb 2024 12:24:29 -0500 (EST) 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 8CA3E6B0075 for ; Fri, 2 Feb 2024 12:24:29 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4FD064072A for ; Fri, 2 Feb 2024 17:24:29 +0000 (UTC) X-FDA: 81747537858.28.61BFABC Received: from mail-oa1-f47.google.com (mail-oa1-f47.google.com [209.85.160.47]) by imf02.hostedemail.com (Postfix) with ESMTP id 91E748000B for ; Fri, 2 Feb 2024 17:24:27 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Po01W4tG; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf02.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.47 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=1706894667; 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=Q6UPWR6ndOUYDUMRqQVrkQUUePvtAQ0pg58MMEcJMl8=; b=QMQ5j6lLR5L1+D5ErAAzQ91axSFgv6sepZ4Fzl/xN4JrWP5piNZyEo0/95ll1GbF8QlOtg f0BQpkFcYXji2Fm42psOmXxRTQsilDzOjfGM2pbomA47TiPFV7KddoveajBD0r2SlvCkOB vt2ZQuzY9hgzvty5E9QpxADOKrcbsXM= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=Po01W4tG; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf02.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.47 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706894667; a=rsa-sha256; cv=none; b=roJcFLbjninm/FEnXeaH9o5fowtbolKMAPBW+UfHMmlOsRXzBMbAfjQ5D0jFvWAoqwv3z/ 2lz51Tmf0hq8bzDLRlQvGKVW1ZBAY2KA2dx7y6JhfAeGGOFmKKGeKHRnGyKkockvrpbjNx uSS2483FaLrzsH55Fm9Y7UsB6p7qP6U= Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-2185d368211so1123121fac.3 for ; Fri, 02 Feb 2024 09:24:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706894666; x=1707499466; 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=Q6UPWR6ndOUYDUMRqQVrkQUUePvtAQ0pg58MMEcJMl8=; b=Po01W4tGV6xhxqRb58R4R8C3DONXBHjHSsTas+emUlG7pqNP/uSahG8a3cCy1dZe+c a1SN8TjrcseDZiESyOHdMyARkcou45aSOc66X9ABnWKZzh7xK0zs3DVxXcH+wcgDDgkJ /wwUQtqcwQVLgYDk5DO69D68GhMbGkaiAGpeM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706894666; x=1707499466; 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=Q6UPWR6ndOUYDUMRqQVrkQUUePvtAQ0pg58MMEcJMl8=; b=Vu/AdmMNfJvLUQJh34xzTEbyh62yK0NjphlU9PcLN4z7clQXuBaMWZWEU7eVc4WJtL qwHicQBZUvd0r2ob+YiIPdjCJQcpzhXvFUO7i8Kh0NXSijvDScPf2kPu3agsuC42ZNPM FPWc10Mh5i0+qGvln56LCk/MKHGfSicNo+SMQt9Qk/nbgK0QIapXu95j/bcT6QQW4VAL Zw3rGKE3Q4qPdEGBcV9mQGuaWyxlks+vCccA4ejKxDzqy94nflI8T4mThH4pridKsxhh /4foIXQH9dG2G6UxawciLYkd6khJBn58vxY1Yv9ot3+bslhMBlBvZaKYpUK6jaJXZQRC xksA== X-Gm-Message-State: AOJu0YxTX0OT/Dh7YSKcQtq841S9kYgvWVelzVOVGeNlsHts4Eghg06q wFA5/QCC6kPxxX7mbmcMCSjrLQHxNq5NG2FgUPtM/llovI6GNPCwcMzpIQtf+XSKrnDITZAFHJ+ zuvoeEGIgAdTEt9BfREvTWa9B3n2Y0XtPlVZ4 X-Google-Smtp-Source: AGHT+IFcpltYRj5g1jySgZ/6GoPjgsQ0yDI/CttpZ6v/mpIaX0DPVPHCVu9NXF6WDXyu3zKUp5cLGz4fA9D1UNwgF/M= X-Received: by 2002:a05:6871:68b:b0:210:a495:ba1f with SMTP id l11-20020a056871068b00b00210a495ba1fmr395060oao.15.1706894665224; Fri, 02 Feb 2024 09:24:25 -0800 (PST) MIME-Version: 1.0 References: <20240131175027.3287009-1-jeffxu@chromium.org> <20240131193411.opisg5yoyxkwoyil@revolver> <20240201204512.ht3e33yj77kkxi4q@revolver> <20240202151345.kj4nhb5uog4aknsp@revolver> In-Reply-To: <20240202151345.kj4nhb5uog4aknsp@revolver> From: Jeff Xu Date: Fri, 2 Feb 2024 09:24:13 -0800 Message-ID: Subject: Re: [PATCH v8 0/4] Introduce mseal To: "Liam R. Howlett" , 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, torvalds@linux-foundation.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, deraadt@openbsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 91E748000B X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: br6yyjg6ma9q5x4hzxcu4h4k3dkq6m9f X-HE-Tag: 1706894667-469766 X-HE-Meta: U2FsdGVkX1+m797r5YBo8k+vrxZsP22xI1sRyIz27qmyOzyoXZXHEC7GiZe4hXRYF3HRkkm9plNbza6p2ZK39boFyZcbjdyLLhWR9ElKCPdjMZOm9G4PPaY9CAr83LhRBB6d2kMa9VMUDw/KYnhakp5RE1tdTRy/sXt7hurc27PhQ+z4Cr2HEsWvKt4ZzeEyKmlZJfL4aTMMDreGwvBzd7rknoJbY/1ExK/Q1YN+/BPGY3LVBF++Ct+k3tcC4DFCNQnbos+X4ka8kDITE4+5+04WovJlDyowpD2XPTHEKxYjO1vyRCpBQ5AzT1DLStAxgKIU6XxGYQefFAfgLLiPivb3rDKcWFPDDLJHJKK5kk+XzawKi+0rT8r7D7zJo+JDqHbt5jZDWi/RO6y676WcUKvf/LWP1kFC/ltp3bl/8VLUkSGaDG8XyXQUTn2Cc7cM4vdwbsDMd/7Pw7HHR7wX/IJN73CFHyuSi5BpF/RV/b7xmOqyDrm4YauDgJL22gFBgX9VAsLh72sIWDWJ/lOZ2cUF+UkP/DdQo18ME7MYe/bfmWUP4G0qM29DKPfw7FkPp8QmyY5Noiynt2ctAGTIhSmhHvCn5uj7EfDQI66iwUBDodG/DfuDZuhV3bsJ0+2+H64tsCEl7vwu0/0Ajb4FD9ghFHBbttuTcdpw+vt48a1nBG5ohbp53ALSQU4jv1dyffEEMeyRDDAlspuOE6G9LQSuQ7E4QpJDlNBiwHFg81i2WbfJ/bbWDrmPZ8kJvDYSozXsWv/GZxV3iKMcS6uH9QMltzBpXyBY0Iq68a+r+1ls5wCcPkT3mIoXOa8dR9Oyxz0J70/02pxHtHIXtvoGTFfT1oBDFpq1w/zocNMzvWl3vDxSdRefHLbyvSh4ckt+rM4yC327DhL27ahkvfwMuidAXH2BttmjvxwqLyYJMW5qOQba9jwFaO0SkstsDHP7TTYT7gs5+S6kK7mDsvf gYiSW0L6 CceoD25VgV+l18otMN82YRqihYnjURRu5mpsuS6dziD4zZTzQAMSMuHfJoX8DW5+ze/Qa 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 7:13=E2=80=AFAM Liam R. Howlett wrote: > > * Jeff Xu [240201 22:15]: > > On Thu, Feb 1, 2024 at 12:45=E2=80=AFPM Liam R. Howlett wrote: > > > > > > * Jeff Xu [240131 20:27]: > > > > On Wed, Jan 31, 2024 at 11:34=E2=80=AFAM Liam R. Howlett > > > > wrote: > > > > > > > > > > > Having to opt-in to allowing mseal will probably not work well. > > I'm leaving the opt-in discussion in Linus's thread. > > > > > Initial library mappings happen in one huge chunk then it's cut up in= to > > > smaller VMAs, at least that's what I see with my maple tree tracing. = If > > > you opt-in, then the entire library will have to opt-in and so the > > > 'discourage inadvertent sealing' argument is not very strong. > > > > > Regarding "The initial library mappings happen in one huge chunk then > > it is cut up into smaller VMAS", this is not a problem. > > > > As example of elf loading (fs/binfmt_elf.c), there is just a few > > places to pass in what type of memory to be allocated, e.g. > > MAP_PRIVATE, MAP_FIXED_NOREPLACE, we can add MAP_SEALABLE at those > > places. > > If glic does additional splitting on the memory range, by using > > mprotect(), then the MAP_SEALABLE is automatically applied after > > splitting. > > If glic uses mmap(MAP_FIXED), then it should use mmap(MAP_FIXED|MAP_SEA= LABLE). > > You are adding a flag that requires a new glibc. When I try to point > out how this is unnecessary and excessive, you tell me it's fine and > probably not a whole lot of work. > > This isn't working with developers, you are dismissing the developers > who are trying to help you. > > Can you please: > > Provide code that uses this feature. > > Provide benchmark results where you apply mseal to 1, 2, 4, 8, 16, and > 32 VMAs. > I will prepare for the benchmark tests. > Provide code that tests and checks the failure paths. Failures at the > start, middle, and end of the modifications. > Regarding, "Failures at the start, middle, and end of the modifications." With the current implementation, e.g. it checks if the sealing is applied before actual modification of VMAs, so partial modifications are avoided in mprotect, mremap, munmap. There are test cases in the selftests to cover the failure path, including the beginning, middle and end of VMAs. test_seal_unmapped_start test_seal_unmapped_middle test_seal_unmapped_end test_seal_invalid_input test_seal_start_mprotect test_seal_end_mprotect etc. Are those what you are looking for ? > Document what happens in those failure paths. > > And, most importantly: keep an open mind and allow your opinion to > change when presented with new information. > > All of these things are to help you. We need to know what needs fixing > so you can be successful. > Thanks for those feedbacks. I sincerely wish for more of those help so this syscall can be useful. Thanks. Best Regards, -Jeff > > Thanks, > Liam