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 8F39EC46CD2 for ; Wed, 24 Jan 2024 20:37:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2A1BA8D0006; Wed, 24 Jan 2024 15:37:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 252038D0001; Wed, 24 Jan 2024 15:37:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F2718D0006; Wed, 24 Jan 2024 15:37:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id ED1FD8D0001 for ; Wed, 24 Jan 2024 15:37:06 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id B474F40745 for ; Wed, 24 Jan 2024 20:37:06 +0000 (UTC) X-FDA: 81715364052.19.5747E45 Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by imf22.hostedemail.com (Postfix) with ESMTP id BF86AC001C for ; Wed, 24 Jan 2024 20:37:02 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=0o7fBzG7; dmarc=none; spf=pass (imf22.hostedemail.com: domain of deraadt@openbsd.org designates 199.185.137.3 as permitted sender) smtp.mailfrom=deraadt@openbsd.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706128624; 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=gma7XJXUl5VDVdINFXGzvo1VwzChIxzy9gf5vCPmZrU=; b=yhwVmWt41ShDk9b2gtd9YvTpm3UtMoUw6A/kv40lsEUW1fsoQJ1FFtPshIH0eAih6qWw+q 9tqphaopsnD6QlhkYurxRJ3uh6kf/UIaLQj7zMV2uaUErAFyQxa/S5QbjgXdK8YdwNnn9G ELH9fORT/jx0T4QqgpEr3ibg3sVWio0= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b=0o7fBzG7; dmarc=none; spf=pass (imf22.hostedemail.com: domain of deraadt@openbsd.org designates 199.185.137.3 as permitted sender) smtp.mailfrom=deraadt@openbsd.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706128624; a=rsa-sha256; cv=none; b=4czOesHQh8XbtKshC4LJ2rOLqHj/B5NJFlzZE7baSMRQkBlMflYbpUA+sHG4H9+eAtSNlh h2ZXr/b7DHCigACtHAtn1oIOaus0KV5MKVS3o1099NiFRnQ8es4243t65ijmF16N2arPEq XwTuPSzBw45c2dlDnMJGNTEvWRpkCy8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=selector1; bh=qAbil4CI0G axYPzRWGXFLvmaTeTW+0u/q2km4lPInBk=; h=date:references:in-reply-to: subject:to:from; d=openbsd.org; b=0o7fBzG7svwTo7Kh/7vEMdx4zsLVBwfhUjx7 LzKHCLemDhJUdJ7kBZaqq01ZZ6mlhV0jWW06VsG6SUsO7zj0FeYsoxnPL9UtPen++V47RQ ErfXssKrPcoH8QLd+hU+jukqcPmjimWifKkdopTDURMn9dO7cqzVoKyFukCGefgWOYXTio xURM/Wusq1CJvrg1T+Azs3147HZSSvjL+B5MXaUTyh8ZOw3ldi6leFFdbZoK66gbnu2Eg3 ///ySdBAMqzJCTTXtIrNNoQccj9/O8GFah537gVUnEWwIe/8wXXjb5KYV0+qI/7G4QlCcH GnAgpHEqv2ufgXUk2hJGztMgSA== Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (OpenSMTPD) with ESMTP id 065cb52c; Wed, 24 Jan 2024 13:37:01 -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: <20240124200628.ti327diy7arb7byb@revolver> References: <20240122152905.2220849-1-jeffxu@chromium.org> <20240122152905.2220849-3-jeffxu@chromium.org> <20240123181457.idckaydk7dt7q2qy@revolver> <20240124200628.ti327diy7arb7byb@revolver> Comments: In-reply-to "Liam R. Howlett" message dated "Wed, 24 Jan 2024 15:06:28 -0500." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <54058.1706128621.1@cvs.openbsd.org> Date: Wed, 24 Jan 2024 13:37:01 -0700 Message-ID: <98656.1706128621@cvs.openbsd.org> X-Rspamd-Queue-Id: BF86AC001C X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 5bkp7yn6ek7etu89pq1sqn3si5768uyt X-HE-Tag: 1706128622-843866 X-HE-Meta: U2FsdGVkX1/WHy/BBUCC3NFIA3830AkFW4qwLZFGx7U1XFfE8jAmcY/zmlNndwR/j+7HF/pVehk35oXags6/jUDUD9uVp4I8gHKPy/kfYzeHwY2P3GSeVUfHBXAcimKuNRa3HhLNmIU/D6+3rTdsr19e7cnhSaUESF1iasiT/7n6Hp30Um/1RGIJhQ34AXPCndb+EgaMzUUoEQXADD/b3CD6BHBf/lufP+Qu5m2djzyGI/Iffd1OukDpTdu6ePhWkA32uyZd8w4q0GeCVGFZROBWcChpFALfgRYE9AL0neeTSwrciODyQaeIRh+Lc7JZ1T7kHYpkYadxnz+hWhzQyftJE16eo+baLKsdI2qFt2Jke1xyPdtfKuJovNCFZmZs1hdNPjOfkm0kXtqDTAPZJ01XN0uM8WKZVdCEIrcu5G//qlDK25Z7Vr9B7k/doO/GY7YmwTtgxY+Gej9sT5FofDm/c22rnlimQ5DzZPgZL1TaK1+RVsPs+h7ao3qTiSet0psv3F6lHYapsiDr05MCmb2U5tM2g0JJ3JXno6rOYqttk+rt3lh69F44KbMGkJZC5zipJzG5sRNTPeNpk+S4QWw0iOQZTCT8MurSbCyml1WuhFp6xWnV55/OH2kEJCzjRd89qCgvfRXX/ygnEuRiqhmgPYY2d7x7qpiz5YTqAacoL16diuPXlUVizbhmp0a+jQluI9Hvcj6iy0vOe9TsF14MdM0pWDgwA4GuwzGXA39mMi/Ic27cT2LKHdohfhejQmWa76DP4EH5hx9rZW/aYb4Dbsx/9nfTCbOJva8vOKuBWXq035AMplt3Uhw4m/hlxuOfcvE82XNJDA7mjZW8fgO2dpPskIwVqwgsVq4wxeJiu3yLVAyXnnANbWKfgzxgJIym/LZKQnbJ/96SUoNKEyBysgW7dgh156Os6XJjTgtn/aG4DxF5ZbwRXNvAje6q3tYwimXhWwQj6ZGo9GE UM5BvByD mAAHxhrMPgY2/SEAJO8j7/2U6Cwb19tCgNlj8UnbmkjX7nRCOjJ/2CftW2b71mfykqwVlVJeXr6fN41mRXjJf9bDNp2q/kz37YxUt2eOPL08d3SEWgC2Ptye4Ss1Ou2331K6FWSVbTNsKNTgcGQVR7VUBdIwV4D62bhRC8VxJVJswzdChRijeaQ8CDZn4+rpeeJBO 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: Liam R. Howlett wrote: > > Adding mseal() into picture, however, the heap is then sealed > > partially, user can still free it, but the memory remains to be RO, > > and the result of brk-shrink is nondeterministic, depending on if > > munmap() will try to free the sealed memory.(brk uses munmap to shrink > > the heap). "You are holding it wrong". > > [...]. We could document above mentioned limitations so devs are > > more careful at the time to choose what memory to seal. You mean like they need to be careful what memory they map, careful what memory they unmap, careful what they do with mprotect, careful about not writing or reading out of bounds, etc. They need to be careful about everything. Programmers have complete control over the address space in a program. This is Linux we are talking about, it still doesn't have strict policy on W | X memory, but misuse of mseal is suddenly a developer crisis? Why is this memory attribute different, and how does it actually help? When they use mseal on objects with unproven future, the program will crash later, beautifully demonstrating that they held it wrong. Then they can fix their abusive incorrect code. 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 to always use MAP_SEALABLE in their mmap() calls.