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 3922EC47258 for ; Fri, 2 Feb 2024 04:04:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C12BB6B0082; Thu, 1 Feb 2024 23:04:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BC3306B0083; Thu, 1 Feb 2024 23:04:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A8B846B0085; Thu, 1 Feb 2024 23:04:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 99EF96B0082 for ; Thu, 1 Feb 2024 23:04:02 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 20495120120 for ; Fri, 2 Feb 2024 04:04:01 +0000 (UTC) X-FDA: 81745520682.15.7B774ED Received: from mail-oa1-f49.google.com (mail-oa1-f49.google.com [209.85.160.49]) by imf24.hostedemail.com (Postfix) with ESMTP id 88175180003 for ; Fri, 2 Feb 2024 04:03:58 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="UzEoOO/3"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf24.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.49 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=1706846638; 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=UBPcz0GP5Gh1HSYLOPzBAm/cEGRCFW+Rm8/XCSszjkI=; b=S0ahN3phl+lPXvsWHg0Ohy8vzAKhQr9uKtOSYfwoRTFbOmbsvUlrJFd4Bp+6zIPtquBJq5 jJjUW7Yo7VNkv8JPyapH1forTG8H1oDabTgZPcjAWrbE2vauMnqgKv/CGEQBvK7R7P3NFA 2K6ZT3zAVLt2KKpI+IiC0ch8VaQcw48= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="UzEoOO/3"; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf24.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.49 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706846638; a=rsa-sha256; cv=none; b=2K6RHcqeVYE7SPtwWGlFtbTehWxfasJaa+wXhQM4tO5jMJwvSXno4yYn+T2K4+pjhs03ha R65bPHKaSbxK0DOsPSjwNoH20hDiZHqI5dAope/n1+BH9UkGpJJrchY/NesWDuxhSZxTni ZQnf6mEaBSMuvGzMWx9OG9XPCs/NO2w= Received: by mail-oa1-f49.google.com with SMTP id 586e51a60fabf-2046b2cd2d3so1209932fac.0 for ; Thu, 01 Feb 2024 20:03:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1706846637; x=1707451437; 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=UBPcz0GP5Gh1HSYLOPzBAm/cEGRCFW+Rm8/XCSszjkI=; b=UzEoOO/3bI3sN/UzTI1i9HgAtfLc87guXYRa4zJmJg8N/NXq9s9QKZ/Rvgq9D8KVU0 wroo+g7VI6O2PZSWnAuzCoItjQ0ZTeoA3gGKPDTbNWYZ7B7jImTFmgU/OXYk+F4C9Mp6 2YP4RdJyXYTsBVluXbdbTq0ils69enCHbZK/w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706846637; x=1707451437; 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=UBPcz0GP5Gh1HSYLOPzBAm/cEGRCFW+Rm8/XCSszjkI=; b=D+829moANl2O2hY5iao1Et+M03AMzM0tMXDIS8BtcytME4CENX3+/gG/BCC9cpY3bf KvML31/EY0geIz0cy1/fWTarm+EKg2QxdgihDQHpNQvTMTxq9soA7YDeMz46Ck268xCN rdyslwMVUSqxV6JT4FMbJYR8F8Hdzh8b9VgiTXKHu6y81SIUnrhj+ptiG0nSdIlseXo5 HU+mhrEHXkU+fZj/RAKWdwFP5ZVAORHmETBacAYtwbp8m7eUTpOd9g81EYXTa4caQM9X bCwWdyYKgAOfwOPTWiN5rowswVaAsEle9oyi3SETSuHmBDEHlnkOrq18dqO0BUHd526s 0jTg== X-Gm-Message-State: AOJu0YyNq0huGlVsRnmdzQ8LeEwkAhSKYKbjFP09TsR12DvT+ShlNeVS MGP7BT44V6Pf122rqDwdA0oZP7Ct8sT6cA4i71PaKUXGPvHQoj+03g3BZy935hOMFkW62727i/6 lPG1ZRNw3u+oJwZcOTwZNPYOFWNv8L1TEgATu X-Google-Smtp-Source: AGHT+IES4sq+g6F4jHLGGFMZ3vUJFlNPbI6MSO0M/CCogUCWKZrbwpoaixxpKt/8wANqpnBcfmTqY5IUCygQOB1rm1o= X-Received: by 2002:a05:6870:40c1:b0:218:e4c3:e34 with SMTP id l1-20020a05687040c100b00218e4c30e34mr4696738oal.55.1706846637645; Thu, 01 Feb 2024 20:03:57 -0800 (PST) MIME-Version: 1.0 References: <20240131175027.3287009-1-jeffxu@chromium.org> <20240131175027.3287009-3-jeffxu@chromium.org> <20240201231151.GA41472@sol.localdomain> <96087.1706846050@cvs.openbsd.org> In-Reply-To: <96087.1706846050@cvs.openbsd.org> From: Jeff Xu Date: Thu, 1 Feb 2024 20:03:45 -0800 Message-ID: Subject: Re: [PATCH v8 2/4] mseal: add mseal syscall To: Theo de Raadt Cc: Eric Biggers , 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, jeffxu@google.com, 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-Rspam-User: X-Stat-Signature: 8gr84jrseytm5up1qzbxsexfe5owfi1x X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 88175180003 X-HE-Tag: 1706846638-654173 X-HE-Meta: U2FsdGVkX186tHDn9UeWT4BgIZAffniUcturo7znXCQzUBHvBV/UetJKFvHSfGr/LgVnaYCpnbuZL6E0Ux/77VogOdvtf7WX//Lt14YisLkFhSHuCicqCNmKcNDKY2IqonTjRYxUvEl2kKq+k2G/ra5RHYzxFp2uM8YQrsBaUd9O2G7No0spS6OO3+HWS0DViJLf3HLjd11sskJNmjjFoJX326DUcLW+sXpJyaT8qiTP86gbOODQITR6YdD83R/SsvOFOMOZnW+MGLhNlXuvKDZ/qWsoYjJzyNTCmDKg4fChxFfaSB/RzIf+BCNE2EifJ/E3r8bn/ct8vVLBCigm7zQLnQBWN7QCyiP0M1d+fY92ELVS/4OSCu05cs4rYYuheQrXMLTKbpi6Lc/G4pGNAsgnRJsBe7FQX+809uraWSlR5sCLkyp6M1PxiozOWuRu3A4m/Gp4u8NGHbaME8cHJtNW/+BMda/OuMxoAk7xf1VogluNJr1ZnGTYlnZsogsz8poo6eqoAVr91G/vB8bdsQxiYeOVJJpbZYgYz1QSv1RcUar2gYinAFAg+EDl/AnBC18FGLYKe9UXRRfld7hWmV0XrOkHQZ98yuqzO47/TWC2BQMOn0HBqrbZUAOQ6w+QyXAPaqHYL/CxmobxAFkzncayg0FYJLHz1F+auh9ruE17j9anQXZl4sxScZQVUQTqTu46ZNv1W2xZUlJaboIDI3N/b0QDV5juUG8w7NYwUg30kQbS76BXtATd4YwNCh9FxCPHG9tC5N3CPHrKHCFjIpFiHxYrRidKv/OiELF7tFjAmxzpy+TBChgtsMJNrdin/Op+/gNenqDnxk3ADWgkn/ZtWphxY9e/p4yyU19ztgwk62p+BH1wt6KOLMUQIuBRMJTBxmtZ5pxgI21n0srqA1yxSaR4c7LaElTG0fmLrzs+cFzJA0fW7c/UOz40lt048M5tLvGLyEI= 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 Thu, Feb 1, 2024 at 7:54=E2=80=AFPM Theo de Raadt = wrote: > > Jeff Xu wrote: > > > On Thu, Feb 1, 2024 at 3:11=E2=80=AFPM Eric Biggers wrote: > > > > > > On Wed, Jan 31, 2024 at 05:50:24PM +0000, jeffxu@chromium.org wrote: > > > > [PATCH v8 2/4] mseal: add mseal syscall > > > [...] > > > > +/* > > > > + * The PROT_SEAL defines memory sealing in the prot argument of mm= ap(). > > > > + */ > > > > +#define PROT_SEAL 0x04000000 /* _BITUL(26) */ > > > > + > > > > /* 0x01 - 0x03 are defined in linux/mman.h */ > > > > #define MAP_TYPE 0x0f /* Mask for type of mapping *= / > > > > #define MAP_FIXED 0x10 /* Interpret addr exactly */ > > > > @@ -33,6 +38,9 @@ > > > > #define MAP_UNINITIALIZED 0x4000000 /* For anonymous mmap, memory= could be > > > > * uninitialized */ > > > > > > > > +/* map is sealable */ > > > > +#define MAP_SEALABLE 0x8000000 /* _BITUL(27) */ > > > > > > IMO this patch is misleading, as it claims to just be adding a new sy= scall, but > > > it actually adds three new UAPIs, only one of which is the new syscal= l. The > > > other two new UAPIs are new flags to the mmap syscall. > > > > > The description does include all three. I could update the patch title. > > > > > Based on recent discussions, it seems the usefulness of the new mmap = flags has > > > not yet been established. Note also that there are only a limited nu= mber of > > > mmap flags remaining, so we should be careful about allocating them. > > > > > > Therefore, why not start by just adding the mseal syscall, without th= e new mmap > > > flags alongside it? > > > > > > I'll also note that the existing PROT_* flags seem to be conventional= ly used for > > > the CPU page protections, as opposed to kernel-specific properties of= the VMA > > > object. As such, PROT_SEAL feels a bit out of place anyway. If it's= added at > > > all it perhaps should be a MAP_* flag, not PROT_*. I'm not sure this= aspect has > > > been properly discussed yet, seeing as the patchset is presented as j= ust adding > > > sys_mseal(). Some reviewers may not have noticed or considered the n= ew flags. > > > > > MAP_ flags is more used for type of mapping, such as MAP_FIXED_NOREPLAC= E. > > > > The PROT_SEAL might make more sense because sealing the protection bit > > is the main functionality of the sealing at this moment. > > Jeff, please show a piece of software that needs to do PROT_SEAL as > mprotect() or mmap() argument. > I didn't propose mprotect(). for mmap() here is a potential use case: fs/binfmt_elf.c if (current->personality & MMAP_PAGE_ZERO) { /* Why this, you ask??? Well SVr4 maps page 0 as read-only= , and some applications "depend" upon this behavior. Since we do not have the power to recompile these, we emulate the SVr4 behavior. Sigh. */ error =3D vm_mmap(NULL, 0, PAGE_SIZE, PROT_READ | PROT_EXEC, <-- add PROT_SEAL MAP_FIXED | MAP_PRIVATE, 0); } I don't see the benefit of RWX page 0, which might make a null pointers error to become executable for some code. > Please don't write it as a vague essay. > > Instead, take a piece of existing code, write a diff, and show your work. > > Then explain that diff, justify why doing the PROT_SEAL as an argument > of mprotect() or mmap() is a required improvement, and show your Linux > developer peers that you can do computer science. > > I did the same work in OpenBSD, at least 25% time over 2 years, and I > had to prove my work inside my development community. I had to prove > that it worked system wide, not in 1 program, with hand-waving for the > rest. If I had said "Looks, it works in ssh, trust me it works in other > programs", it would not have gone further. > > glibc is the best example to demonstrate, but smaller examples might > convince.