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 E263FC4332F for ; Thu, 14 Dec 2023 00:36:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 657426B047D; Wed, 13 Dec 2023 19:36:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DF806B047E; Wed, 13 Dec 2023 19:36:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A7F46B047F; Wed, 13 Dec 2023 19:36:07 -0500 (EST) 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 361576B047D for ; Wed, 13 Dec 2023 19:36:07 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 040968028A for ; Thu, 14 Dec 2023 00:36:06 +0000 (UTC) X-FDA: 81563556774.12.D09B33F Received: from mail-qt1-f181.google.com (mail-qt1-f181.google.com [209.85.160.181]) by imf26.hostedemail.com (Postfix) with ESMTP id 39B1F140016 for ; Thu, 14 Dec 2023 00:36:05 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EyGgz5PM; spf=pass (imf26.hostedemail.com: domain of jeffxu@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1702514165; 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=Rh/JIPLuSc5XTJsnIXetpV5afhDLqc5qWgt+ZxYeVCQ=; b=iJJvT4MNMwYa0tvdeY43HxO5cJuvNVfdSQ1OIVkURkpE1LPqbCFhUMC/vVCVjW2cLlkSie mrtOJpS/ayo4Q9H95lry6fo0dBTccM+Af5oR3hXHCDUotGl1yf1eeEMN0UebaK0rsap8tV I0ZLpGoXJOs5fDwlkKaoBRgvh294qJs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1702514165; a=rsa-sha256; cv=none; b=HXcf63+nQ4wQJ1URJIau3k01qs6+YW50pDRwg59wTL0/nglEO4JJ5bSSN9yDEf4Q0yLci2 5vgDz/0BvwjgGGAOxuhgP1jMa1YGEGJnJWrUiMzejpIeh1XMcG+RO0x06LHE2x665KbUl9 YWZXs6DVuwRECYdZ9X/dU1DlIVRTyr4= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=EyGgz5PM; spf=pass (imf26.hostedemail.com: domain of jeffxu@google.com designates 209.85.160.181 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qt1-f181.google.com with SMTP id d75a77b69052e-4258b6df295so140141cf.0 for ; Wed, 13 Dec 2023 16:36:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1702514164; x=1703118964; 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=Rh/JIPLuSc5XTJsnIXetpV5afhDLqc5qWgt+ZxYeVCQ=; b=EyGgz5PMXOwtz3JpT6IzEh6mUFUsi+4I1sZ67BzNV565YK2cWXej+H32BDSwQcozyM biKReZcjHRziW36EXtsIUKszmpSFUmN5uR8YhT54kRjuq6MS40CCFB0nvc40kKgwdrbx PZzAzDsPgMp1vlJ1z/a/oHvLRDcUPT1tFKapQXLl3ie1oQJmhs/OvoHLmVLWjMrPqcPe XOC3tV1/Dba/Exp+uoYTAC3UYbwIecqm8SKS57ja4kv0ZsgfmgUlyrisqdnlD2PzMbXW u8qqv4f6tOcGaJ3tCvbWMjevHnPMCtQNY039vBUirPZ1PW1cjR9BIwBtcT86YM3hGTPV 3Y5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702514164; x=1703118964; 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=Rh/JIPLuSc5XTJsnIXetpV5afhDLqc5qWgt+ZxYeVCQ=; b=qGqQucmghfpmDXHX+LV4I5Lqm077U9joepBOyibVuKmvjROHSxlJVylzIJqzZszvzW 53gw4dNARTCupvReU8gDKqTIddIPB3615roH0U8q4fr5i93SCR08uEwNmps/uW7qSRGc gl8CWJYp7nGb3kkiCp8EA6FQ6A251suBa9CK0uwN+gbIEQlta6VE8F0cVaXqeGpbT2B1 08X13pe/Stq1dxWfTywzdJbXOAud9uI+lzYdQLbN+ZWhhbmsM2kf2F/BdlzH2lpmngBW iZRoasrYqF7/SGyN04mtt68slrGMzYK4zpqTl55Wm5iZQzK8Qp7TmQ9kxZASkD1iHy+L MtDQ== X-Gm-Message-State: AOJu0YyckbwNZmpNpoPEFkAHxt2ck2yR9XylRLr3Mp2XuIZGI/EmYk16 co2JPC6A/0NfsClY6gUzKOofcm0wHD+prB/m6kMyUQ== X-Google-Smtp-Source: AGHT+IFV9mswBOSTplU3GbpxbWwY83oDLBB8lfMgKwsXIlFx4/MATC30VcWkHbqFp7WCIuN5thSLGmaeWN2qqtvo+f4= X-Received: by 2002:a05:622a:1a15:b0:425:47fc:e6e6 with SMTP id f21-20020a05622a1a1500b0042547fce6e6mr1655213qtb.4.1702514164149; Wed, 13 Dec 2023 16:36:04 -0800 (PST) MIME-Version: 1.0 References: <20231212231706.2680890-1-jeffxu@chromium.org> <20231212231706.2680890-12-jeffxu@chromium.org> In-Reply-To: From: Jeff Xu Date: Wed, 13 Dec 2023 16:35:26 -0800 Message-ID: Subject: Re: [RFC PATCH v3 11/11] mseal:add documentation To: Linus Torvalds Cc: jeffxu@chromium.org, akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.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: 39B1F140016 X-Rspam-User: X-Stat-Signature: dpaapqzjqpnca3w8aq36om695eexq5qa X-Rspamd-Server: rspam03 X-HE-Tag: 1702514165-655368 X-HE-Meta: U2FsdGVkX18RrjgtjnoJsTsylb16S8fLiHufgH9466r9R7Owy20YXfg1rwQ0wiuTJaSmScC344ytzqjOaU4R++D3Wmi+IA7HA1sDPtHte1EubWMLWvdjrNJ13sD9wd4ISJ12rNPaYY4aGRjtpLV+R7OWOPji9FcCgBD2VO6zMYRsSU2MCGzGUhRZ51Gk6KEbfOvdCnr8dMIeaaB4slg3oYfljs2OxfQuWJP4Wx1dExPpSvFvum/sNDDoDRSh0qI47lEO8zAR2cspK+SE22sSGpU6krz9cl/RD5VuiPHksmnidIlTHZroMdoMB661YQyXuhSadykH06XVH3R6OG5wlymbu7q+ITlWrbUFGqbNdo7WDgKSpwqZpxqN+Tgi1v29dc8xz6BVoH9ine7kWVolNcEC7XzEJ99BGaCttdaKeqyBa4z2v5rAPvGxd5h9UX1lW8guKTiZTD7FGFKLpgMJAVi1/BVj+lwfkujetN97oaT5dH2HB66G55nascZSOgAbvU+0ZuvLhNNT3EQwr54eUqp84S+33EO4GexE5Iw5Cb9sh6MyuXehE3JDWHX92p/uz9518p5eSWM6tjqO0eXZYDPRO9cpOvqTVeY8GBI720ZlJvnOM1xB9Sab1VHFmGyttxltXmN/LvTqggiRNnpHHqhv8IwfnJVH4BEb7IbDgmpTv8hQFPI8MxwXbKEEoaz6XGMuRN54wqW6mqpsx2DKJFqiWK4mn4RUOcN6gq2bmNsWTtPEzpz/mWNAn+OeFP2vJO5U7rl16tEuBfT+kjkyFPAiLF7PcmDT1OLv4UnvbgKTArW9S4pV5tdQtseVkK5xwf2mCQziThojao0csi7zulA/Xz3HMmD8LKCEtklYE4ReCWFw9ty80BKr6Yq4j52RyzT3MfuIdWp3Tk2q5ex6z+tELPmL2WbGaOT6o5K6wryiHXGNTwzHjYiAkStVVjgOx6WpVJ9oMBRr6bcid0a +VVVsOoB oJYLdR3S3bWenhC4GJMltDAo7FNsnUMZQt36Uruw3CITISRGNsPnNjPMrPxAYuPe0KxoIciWD7O6EHXXu6Ve2Oy2NWZH+m5p/q4dtPu+3M+jlgA2oxuBYIFS/99ZMv1DMWYOSqMx7GRYnhZr+/payYidbTne1ZDYHnntQZ+FhYXKMowdzXhvGsl6fvnHG+29HN4Bcw4nkpMdoDCWgEA8XW/4KzypEw9vXp1/rgGCX60Emr26N4XIhGWxtQ6mPYLwg8upeR/30vJH1PmHHIKCij/PxJyHT2zIgrx00j/b3R7hl0/ubpWQ1Njmd74ADbye98iK60muunqgSnbr9yo4Nn0XsMPxNt9Teh0WaT5nbWrXeFMNk93tki19vKEQAu2L7bmKeXd4bj8gScovk6bEvRwAuYjbbQGvX87s7yLNAfezjIymFMfizVpaQJBH4tSFN7bOclzMmrwaxGnBImELG/fo5gi2UqXXyRkMRa0DMl1Cm5Xax3GRRyBU744qSUrQxTfzRY6NpXo2wEGm2PrN7aCkGXuYS297U9wwbQk0lXY+kKlWAR2JkGVr9hQ== 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 Tue, Dec 12, 2023 at 4:39=E2=80=AFPM Linus Torvalds wrote: > > On Tue, 12 Dec 2023 at 15:17, wrote: > > + > > +**types**: bit mask to specify the sealing types, they are: > > I really want a real-life use-case for more than one bit of "don't modify= ". > For the real-life use case question, Stephen R=C3=B6ttger and I put description in the cover letter as well as the open discussion section (mseal() vs immutable()) of patch 0/11. Perhaps you are looking for more details in chrome usage of the API, e.g. code-wise ? > IOW, when would you *ever* say "seal this area, but MADV_DONTNEED is ok"? > The MADV_DONTNEED is OK for file-backed mapping. As state in man page of madvise: [1] "subsequent accesses of pages in the range will succeed, but will result in either repopulating the memory contents from the up-to-date contents of the underlying mapped file" > Or when would you *ever* say "seal this area, but mprotect()" is ok. > The fact that openBSD allows RW=3D>RO transaction, as in its man page [2] " At present, mprotect(2) may reduce permissions on immutable pages marked PROT_READ | PROT_WRITE to the less permissive PROT_READ." suggests application might desire multiple ways to seal the "PROT" bits. E.g. Applications that wants a full lockdown of PROT and PKEY might use SEAL_PROT_PKEY (Chrome case and implemented in this patch) Application that desires RW=3D>RO transaction, might implement SEAL_PROT_DOWNGRADEABLE, or specifically allow RW=3D>RO. (not implemented but can be added in future as extension if needed.) > IOW, I want to know why we don't just do the BSD immutable thing, and > why we need this multi-level sealing thing. > The details are discussed in mseal() vs immutable()) of the cover letter (patch 0/11) In short, BSD's immutable is designed specific for libc case, and Chrome case is just different (e.g. the lifetime of those mappings and requirement= of free/discard unused memory). Single bit vs multi-bits are still up for discussion. If there are strong opinions on the multiple-bits approach, (and no objection on applying MM_SEAL_DISCARD_RO_ANON to the .text part during libc dynamic loading, which has no effect anyway because it is file backed.), we could combine all three bits into one. A side note is tha= t we could not add something such as SEAL_PROT_DOWNGRADEABLE later, since pkey_mprotect is sealed. I'm open to one bit approach. If we took that approach, We might consider the following: mseal() or mseal(flags), flags are reserved for future use. I appreciate a direction on this. [1] https://man7.org/linux/man-pages/man2/madvise.2.html [2] https://man.openbsd.org/mimmutable.2 -Jeff > Linus