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 48048C46CD2 for ; Wed, 24 Jan 2024 20:51:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AED9E8D0005; Wed, 24 Jan 2024 15:51:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A76658D0001; Wed, 24 Jan 2024 15:51:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 93DF98D0005; Wed, 24 Jan 2024 15:51:40 -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 8088E8D0001 for ; Wed, 24 Jan 2024 15:51:40 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 40A00803DF for ; Wed, 24 Jan 2024 20:51:40 +0000 (UTC) X-FDA: 81715400760.09.5D774EC Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by imf30.hostedemail.com (Postfix) with ESMTP id 438AE8000D for ; Wed, 24 Jan 2024 20:51:38 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b="43WCwO/h"; spf=pass (imf30.hostedemail.com: domain of deraadt@openbsd.org designates 199.185.137.3 as permitted sender) smtp.mailfrom=deraadt@openbsd.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706129498; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fYaXq5b08WQ4EtjgoGrtivsJuo+jrQUBjKTPesTH4+k=; b=CiUrGR4Rl5Qd1JBFIuQs/KHEWeL8PGv9ERgxw6SABNkrgQOUFnNUFB9AVcwa/YOnq7NpQt xmK00AUwqsMYOta0cRa5K9L/mdlMzo54IPi49z6+7izasKK99deTKLicmlmqomOKbLbLD8 /6N0LauWuYMhHCkWni9XTyura3//gCc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706129498; a=rsa-sha256; cv=none; b=ioqH+d8cHvYXplUQAcS1qc5+gzEim5pnlQRHqXm5eu3EFcSIgRYAYA3tT0PAgRNrFXtazg plk762vKk66TzCHiJEoCcG1OB49GWTJ3ARao1SmIqGW7j3YbyVpfn3sR/dQ4ytQyw7torX 0+tNv0ViAaARMBDy+nxLMYLRlFlOZJ0= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b="43WCwO/h"; spf=pass (imf30.hostedemail.com: domain of deraadt@openbsd.org designates 199.185.137.3 as permitted sender) smtp.mailfrom=deraadt@openbsd.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=selector1; bh=Z6R0DSevUs Wp/ES4X1fSbzidtHovZqFHyGVCe23vpOQ=; h=date:references:in-reply-to: subject:to:from; d=openbsd.org; b=43WCwO/hWJyeW7jniZUXpoRulSjG7aM+cwLo LzWTShoquiNAk1T+jrBK6SMcVIbDB+V51FxS9Zuoa7yiu+uJnEuLsJ/yl3R4QijJGWRmA+ MuBAO63A7qp4qRUizMMMzUN6XAGwCoXnwb0F5rMrZ4VU9kSXuZdV+Jj/ccK03N0lH3Umrl MN7q+ffha9DN63HMmBAKUyeVOvCqaJdaDlJ+terJSrnNEtPcy/81YKlwfVbfv9eMhcxKAo 9EwcDoScJoOvaPYrzj+sXkmj/yw3YsTkr8zdGWgUHmkb4NzKMV5P7efFXj4UsndWP7FpdP viVTF2l2zifSmurxqYEMPZ+8LQ== Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (OpenSMTPD) with ESMTP id 302f01a8; Wed, 24 Jan 2024 13:51:37 -0700 (MST) From: "Theo de Raadt" To: "Liam R. Howlett" , Jeff Xu , 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 Mail-Followup-To: "Liam R. Howlett" , Jeff Xu , 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 Subject: Re: [PATCH v7 2/4] mseal: add mseal syscall In-reply-to: <98656.1706128621@cvs.openbsd.org> References: <20240122152905.2220849-1-jeffxu@chromium.org> <20240122152905.2220849-3-jeffxu@chromium.org> <20240123181457.idckaydk7dt7q2qy@revolver> <20240124200628.ti327diy7arb7byb@revolver> <98656.1706128621@cvs.openbsd.org> Comments: In-reply-to "Theo de Raadt" message dated "Wed, 24 Jan 2024 13:37:01 -0700." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <38861.1706129497.1@cvs.openbsd.org> Date: Wed, 24 Jan 2024 13:51:37 -0700 Message-ID: <82138.1706129497@cvs.openbsd.org> X-Stat-Signature: qqi5b3dzg6fgryexzt755d1wkq5op7ft X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 438AE8000D X-Rspam-User: X-HE-Tag: 1706129498-287248 X-HE-Meta: U2FsdGVkX1/3K6e7oADjL6FrEB3y7qjgyvDKalFwSpfBPuxdfNJZYUKEDnC3DH9vAjnM/hMcT298UKLSzpdQUA5DP1UYVTVeTq5IXTzqavKfS9S9BkMB6chKlvbON/x17r2uaq+lW/1gvorH8IhOKe1pHe5h68PpdOP0R+32Q+ieoD5O4Bg7QHlD05247jCs0FBWyCD1w+cAORHdxK2QU1r4/rQgAJp8nBIax8f3VwUg8qJweGGKWWOJqcyCZucxrffIPpg8O0hv2INUmfEloffbu4pLx9ERjT1o/hRjh/i/mzwAgZI6pekNfZAi1U5bFpHUpwAIF4Vgn8VMTVKNI5eFBJgd7MmrkA5mxuPGOepIOQqGQNPQEJNtjU94c4Q1V0K15bxsSinbnHEIOF78ZD2Bh3BGcNBgWlQW3kfqXN/jEO3eMlOOxPj1TBDsmB9usYQ+0kmc34RQzMd5dXOpx3PhJBFnIEBGE+2YU90e1mZtJ5YVbdXTcGmuYmiixf8XUEGp/fPvwY4tuBnwxrastNarj3I+OPRwhn54TOf+orMvsXOAVJp+xGk9tUIubYHzMiA3Y9ML64TFi5u6WdV8bQ1r2o0bWgY4PR/VxyjKraoyKRyrFglEsZqx6I77MJtp0N7lPurJWDWMGRnaaOVFtwyCPG/6iHS0pMu0w0k41SrL+IqQD3DZBe37lQ3y6xlIuqzCrYM5kykMt0djD/Ay8Shbsya+pLdLI8W0ue60PSjflBDU1Q1MgX2FClDLWssH/TtYItnt1nbLu7WbJayewy8CoUJqlQFetpRiEccGHvkf/AJir+Nm/wxtiV8gGBriJNlAj9ilUY0OUJzylYIFrrcpQi96ANTC2T7XgrFXxJxWjt0xf1eXaZtefzsEBfYL8uW3sAzBCHHceFq/pPP/Bn73hXaiA5EhRD5J4yPS12cqaqk+h/nfYn7cU/YT6u0k+GoI48CZDt+HvQ0ViFu /29COCJJ eqkskrSM7oU/7+6o2isX4dVX9trczB5XDrGXCshdhe7Kulxz3DBdqMGd4a0lfVUgC++vwSOIxecTw61R64H4c8Ocv7DrAb5Wr9LEvNGDdS9RtrtRyWBCfxlEvGUKQqQTafLyWSt1mfE3xbF/g7do72AJCgkp7utCmNloEgzrHTR29vkkFSoCtiuqC8w5TOoIjji8HnjEInG0UPVmuGSxK0IEdTqQM8wr6UfBmjzXJQDrdjb4yv0H9WWp7gPQhohd6vWNuuHQkr+Aki14= 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: Theo de Raadt wrote: > This discussion about the malloc heap is ridiculous. Obviously it is > programmer error to lock the permissions on memory you will free for > reuse. But you can't fix this problem with malloc(), without breaking > other extremely common circumstances where the allocation of memory > and PERMANENT-USE-WITHOUT-RELEASE of such memory are seperated over a > memory boundary, unless you start telling all open source library authors ^^^^^^^^^^^^^^^ library boundary, sorry > to always use MAP_SEALABLE in their mmap() calls. Example: 1. libcrypto (or some other library) has some ways to allocate memory and provide it to an application. 2. Even if this is using malloc(), heap allocations over a pagesize are page-aligned, so even then following assumptions are sound. 3. I have an application which uses that memory, but will never release the memory until program termination 4. The library interface is public and used by many programs, so the library author has a choice of using MAP_SEALABLE or not using MAP_SEALABLE Due to your choice, my application cannot make lock the memory permissions unless that library author chooses MAP_SEALABLE If they choose to use MAP_SEALABLE, all programs get this memory you consider less safe. Exactly what is being gained here?