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 B4F02C4828D for ; Fri, 2 Feb 2024 00:26:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 419EF6B007B; Thu, 1 Feb 2024 19:26:29 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3C9E06B007D; Thu, 1 Feb 2024 19:26:29 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 291086B007E; Thu, 1 Feb 2024 19:26:29 -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 173AC6B007B for ; Thu, 1 Feb 2024 19:26:29 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C4F62406CD for ; Fri, 2 Feb 2024 00:26:28 +0000 (UTC) X-FDA: 81744972456.17.E3B4815 Received: from cvs.openbsd.org (cvs.openbsd.org [199.185.137.3]) by imf29.hostedemail.com (Postfix) with ESMTP id B1BF8120007 for ; Fri, 2 Feb 2024 00:26:26 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b="VpaNj6/i"; dmarc=none; spf=pass (imf29.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=1706833587; a=rsa-sha256; cv=none; b=DKr0cROIqZX2+Vrd6jG9HeWl2XC/q4fj1KJq9Yu83lCfIIhUWJ2ljCPcHsAZrt9nuCjTrR kZ+00XuMr7NXOrgHC0mbqEazgfPvsJ/6XuP1PY8RzCVDVIoZoU3qsTGyLDktKCq5DcKS7S zMvWPr2qnL7GM0Dv3vooVJlEjd36MBg= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=openbsd.org header.s=selector1 header.b="VpaNj6/i"; dmarc=none; spf=pass (imf29.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=1706833587; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=dbPWnwvfirRkI8SXzvINn/79BO8VGA4XYa/aWpIJouk=; b=ab8RjEd4Zd9ANmNg9rC+gGyi7A8CO/QIUPQ94gxIf6j8MfPz6s0X2MWasXWJLQEYSjt2s4 kCfSCjl37zQzqjK9s31XZJ+YSYI41jXt4ia1k8M2DDnB7hDXCt6J2ZJjfBXQxq1GnN+GHM AscDVWiXnkPKVesbwmkb2uOWsZAiwBM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=selector1; bh=b4nuzlN7OX SDkEKK1U2oo8Q0qvyu895tOHZwmXJZYZY=; h=date:references:in-reply-to: subject:cc:to:from; d=openbsd.org; b=VpaNj6/iRziFx+GU2tpihBVG7l1JHFd8a A7GD2CdvaEXIouZOIYmu0HkU7Yjro1oIcecAG+ryKntLWNqbB91QFrgRsVyh2DreI/KG0m BZYC8k786h0blH7dnoSQRuOZEsAfQtUl8+laLj8lX6X7GqGJYhR62VVjydW6zOWbPtl4RC wzPNQdbU6ZUjJ6BFlwKspHNooi8k7EbWpFCzTMNqPnkNqGmbj3mU3Gk8EMW9QiBH/F4Wcj TvHiEjL8XJZm3ChSiB6KS0njSQG9uZqD4vdBDZOgwq69zsLHW6+ioFjQrr29Yrhpx8MJ/X j4IjI2I3Ntjm2p8fN6H7i4JoipVtg== Received: from cvs.openbsd.org (localhost [127.0.0.1]) by cvs.openbsd.org (OpenSMTPD) with ESMTP id 5744bf5f; Thu, 1 Feb 2024 17:26:25 -0700 (MST) From: "Theo de Raadt" To: Linus Torvalds cc: Jeff Xu , "Liam R. Howlett" , Jonathan Corbet , akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, sroettger@google.com, willy@infradead.org, gregkh@linuxfoundation.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 v8 0/4] Introduce mseal In-reply-to: References: <20240131175027.3287009-1-jeffxu@chromium.org> <20240131193411.opisg5yoyxkwoyil@revolver> <20240201204512.ht3e33yj77kkxi4q@revolver> <58408.1706828083@cvs.openbsd.org> Comments: In-reply-to Linus Torvalds message dated "Thu, 01 Feb 2024 15:15:27 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31812.1706833585.1@cvs.openbsd.org> Date: Thu, 01 Feb 2024 17:26:25 -0700 Message-ID: <7481.1706833585@cvs.openbsd.org> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: B1BF8120007 X-Stat-Signature: easf97phnfo7d6j8sifpjm8dcko9sit3 X-HE-Tag: 1706833586-564453 X-HE-Meta: U2FsdGVkX191JFqO4caNXFzW3shzOsyqY5fcW6gT6adBO31b6D0ZeII/2bG6ctejH2qdjg3Ok6/XR96J5PPJ+0fhdH/hZP9BC8xFbXYyYwRzTVDjte68LaE7N0g9mbrSeWJk89RqAPOK3eYw1T2IkzuxpxheKwYwVoigN593PPHiHlgGrD0AMyQAaIcMLxuZvgC7ap23aoSYsL6bHY+kDEP8YYOTXhQbdFU5OAi8iEwMHVkCMcbCJ275wyM3h+ySKSRuyaTleFNEmtOU7JvOZnEi+0IDUfAuc0AHFaDenu9/C2I6S/tbsbN7qlrB5SVgjK2LCA5SSqHM/hu2Tg2TpyBVOwimQOX6VQmfRVmAGwe8aIZ0wJEc5qjSo0roVx6HP7B57Mdpt0dklsqp0DWtwxJBk9THCvXCiwsVWaQRzRNjDa1DwZUSr05oEs9PH7bUCymdcCd/9MJCPcIipRJoLfQlQn5xj9B+kNqBqEb9n3+V2ivJdsz+RX3AmaZvPiY7joYHY8SBcj3wPH1z6tXrGpIcPZtyi20jU0LbjFF33agQdWZia2IWqmd/Dn+hGIm6eCBG9KKZsMZdFJ4zFTePNnoRx94NoWgEs+zV3hgSwp0sSvrhRSfuS/zGlXrgHFqSGVCkSQft0sAwMihTb81ColAKekn1lFuWHvK5C5USK0jQKn+uYNl6f1t7Cm47PrqxN+xUhKe0pG4hqU6IcCBYKzeWq518UiBLXfKalGPWLKDyPsTNeKVD3Bxn7YN8IIugUUNiIRjKaUZvBoacjEYiLHA4XaW9H2bemVbpFi5BdAVlbaXNlSwvxaCxV4u0/I63ze26rkE8ZxxVmN2Cc4Mtyihjhs71fdMq4kvmhO1clZsMJMpuYpRK8KTbui6J2noJo/COz5kH3xaEDtczU/c5/OSHUdQI8IWcYAQ+uerKN9lci/nOchHrpClSBsO3oYCYuX6DqE3VCV7bNO5NkU6 j7ub9eSK O7GX/elFbi69aZ7Lav1axL+H3MX4k1oY+IK4XGp4V2/kdP+3KEQNsk+0MLrews5BpAsMffIaz4Rr8o3msuZhi/25kOdIqEt7nH/MJh191ffy2XT5gKZrA+hhFmfZeb6urejsOs3vUOiWAyBDUG7lbsy+yn7LjVECDHDXy6r4m6VxN6OaFSaSYdaCKVn3bFd5vPZ2uJsD9UQooohYo9eC58QJbhF4zcHN+8yDImL88iFP97d0I4sLK1D6isSOB3h37slk2YiMAno7qPfE= 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: Linus Torvalds wrote: > and using PROT_SEAL at mmap() time is similarly the same obvious > notion of "map this, and then seal that mapping". The usual way is: ptr = mmap(NULL, len PROT_READ|PROT_WRITE, ...) initialize region between ptr, ptr+len mprotect(ptr, len, PROT_READ) mseal(ptr, len, 0); Our source tree contains one place where a locking happens very close to a mmap(). It is the shared-library-linker 'hints file', this is a file that gets mapped PROT_READ and then we lock it. It feels like that could be one operation? It can't be. addr = (void *)mmap(0, hsize, PROT_READ, MAP_PRIVATE, hfd, 0); if (_dl_mmap_error(addr)) goto bad_hints; hheader = (struct hints_header *)addr; if (HH_BADMAG(*hheader) || hheader->hh_ehints > hsize) goto bad_hints; /* couple more error checks */ mimmutable(addr, hsize); close(hfd); return (0); bad_hints: munmap(addr, hsize); ... See the problem? It unmaps it if the contents are broken. So even that case cannot use something like "PROT_SEAL". These are not hypotheticals. I'm grepping an entire Unix kernel and userland source tree, and I know what 100,000+ applications do. I found piece of code that could almost use it, but upon inspection it can't, and it is obvious why: it is best idiom to allow a programmer to insert an inspection operation between two disctinct operations, and especially critical if the 2nd operation cannot be reversed. Noone needs PROT_SEAL as a shortcut operation in mmap() or mprotect(). Throwing around ideas without proving their use in practice is very unscientific.