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 3B6C2C47DDC for ; Mon, 22 Jan 2024 22:10:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B13FA6B0089; Mon, 22 Jan 2024 17:10:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AC4AB6B008A; Mon, 22 Jan 2024 17:10:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98C378D0001; Mon, 22 Jan 2024 17:10:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 89ECC6B0089 for ; Mon, 22 Jan 2024 17:10:32 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 553FF406F6 for ; Mon, 22 Jan 2024 22:10:32 +0000 (UTC) X-FDA: 81708341904.10.DEF6023 Received: from mail-oi1-f177.google.com (mail-oi1-f177.google.com [209.85.167.177]) by imf12.hostedemail.com (Postfix) with ESMTP id 7FBF040020 for ; Mon, 22 Jan 2024 22:10:30 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=W0PaAK8c; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf12.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.177 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=1705961430; 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=C1De09a1ONpOwX9iKnxbH9ncVw4V2gLmkFQIVKMLMpk=; b=c1ZzX/LEqgZy8G9bpNbZlbalPWWhSBRV8LC+9IqkiIFW+9dCcmNOae7ameJNxpf3cWDDRN 7hW2nOMXv8GPXlnKqtQaDqX5dvJm6maDalABAow2sXu9aXECu9iLajc1tAwlVTIcoCnx5O t1X9kEEgf7n6sHY/uqB+MRcf2TPvxO0= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=W0PaAK8c; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf12.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.177 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705961430; a=rsa-sha256; cv=none; b=FajfG2DApINvJVcF6zSGBmOa+LBNSgDS/W/r6jGGuk64G8HE1RB4Y4xy9YdDbbY73op9Mx T7j4zAwbStPPqIbKQSKrGXKHXVb2rSu6F4bsE+fb3f+yTfvGlrdweNxtAzVNb1enDCcTzN sIwS9SQnqg6zLn/fGT3+s6HBj+2s0is= Received: by mail-oi1-f177.google.com with SMTP id 5614622812f47-3bdb42da0e0so1319445b6e.0 for ; Mon, 22 Jan 2024 14:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1705961429; x=1706566229; 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=C1De09a1ONpOwX9iKnxbH9ncVw4V2gLmkFQIVKMLMpk=; b=W0PaAK8c+l0qNwSjQq20Pr09CfnCWxI+nFOML1GeC4iXPrgVfsaWjVbgR3RZOUCP0u lEwZKKhq6r63l+lXQ/7QMoZWH5+qNRb5HcZiybVstpTiApF67KD+gIcHWVy6VqllSsFg 9+WpMiNMexvcMHolN/wKDxRL9rmpuC+Z3UHJY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705961429; x=1706566229; 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=C1De09a1ONpOwX9iKnxbH9ncVw4V2gLmkFQIVKMLMpk=; b=tQ0Ij78TxMO+8K0hd9LN7Io+9Y0lX2dBoLnRO+4qVKIFcCy9r0aSpaC1D341Xk1GNQ iNlss31VoKDFHDvjC1kcFN7gUutwDbPC+sVsDEeoVUnDvwq53C52uQW+9aMfAKPOc8ax 5Jo6BaIRFfMsqItDssHsxLPJsSMBxzYiBaqqjiwSWPEsjq01SwJqxZ8yRvw37XNnbEQ9 py3hio0V0xOn5Tr4InJBk2sqfpHTYx7NyAG41+ZHyxBxU+heFPnKZUBTlJDyyFxXevOW 6GE0E2/RNrIgz0V6xR1Ffgt7JDOW0GOukkVK8z3YSuOw+ZK3+MMOj3ULWFGbWraFgAeq fmIA== X-Gm-Message-State: AOJu0Yx0NJbLSPbwiP45Zd2bK+h+YlJS5LGGDLUy50L6avHkAV/myRiM zkCFK53uRAutpYH6+7A+BgkqZDjUk3FHRoiCsWfQfAOhL+LBcCap4n48tyLs4O9zAh8h0Sqp49F hlIkp3Kp6P8L2R8SLb5bKBcJkR80nBsR7N2r0 X-Google-Smtp-Source: AGHT+IHcyg299dW8RhR+Matblnlc5rb+jBuh+9Itmq6kqEedZQWTv9HU9MSIZbsIZt9nIEh+qA7ZWFl0NFfvqIFhDM8= X-Received: by 2002:a05:6870:e40d:b0:214:807e:8a05 with SMTP id n13-20020a056870e40d00b00214807e8a05mr474569oag.2.1705961429485; Mon, 22 Jan 2024 14:10:29 -0800 (PST) MIME-Version: 1.0 References: <20240122152905.2220849-1-jeffxu@chromium.org> <726.1705938579@cvs.openbsd.org> In-Reply-To: <726.1705938579@cvs.openbsd.org> From: Jeff Xu Date: Mon, 22 Jan 2024 14:10:17 -0800 Message-ID: Subject: Re: [PATCH v7 0/4] Introduce mseal() To: Theo de Raadt Cc: 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-Rspamd-Queue-Id: 7FBF040020 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: e9xm5zsjesbx8kirmcrdqi9i7iuq4i4k X-HE-Tag: 1705961430-75975 X-HE-Meta: U2FsdGVkX1/k9mZdJeK41T+aCXj8vssXYbFYwzJMuMWrd/LGRKuQDkPHgznkaVbGruJtWZCWKgBIga4ft51LbKZasf7gxABsV1wI3V6k32SaC5WHQTYmIOMBL4UREmXh8U8ufpTT1RUB48ntJqVhA/LaCwr8NZV4a+GHFdKgelavbMu0SEJuxRv9Z3XreG2G/4PzgHr+kYM6uIpWpWxe+fBB2PN1wHyoKznBaupaKqbfiLlBsZei0cUlkKm/gKyEDzF7j6B2AKCm2Q2zuFr/Tu/QG/RvijYUTrHU5QZQlJR1+l4kzaMH7lPcb9W3oMoK7cgTiZWNcXQ09WOthFJIiGeoZ3qUwwJvO9GuiDcR342GYcw1hf9JzsoDnAC5Qe0odoNCZnyTnROkdNZ7lqJh8JG/sXaSCEFgepXIykJl2DL5wxw8+Z3GYla3Wu6Q4gx2uPQCqZFHn6Mnq1pKf343yiex1vpbD9STX1B+YXZINulLy48TkBwTW5NhGqQ+hCWsga7GK1zbkwgnr9v7z0oOmvIEIfPhVMClCokoqz+/+pxLCrqgexsHUAVT9YT4GKxhPRD8jIaZwN93l2XybLYrbmej7mIOs2RDmvb+htFCvrruPQmXMHgu6cui1g9KNfxQmZKnSSeALbSK5AdZ1JlA6U/58kWw63wn/g+Go8Y4kKtXB9b0+CI1qwmmctYWT6i2RWgSx/nD1qRmnRkrC6uAYvS8RvTQXaHtgzTPnAItFQuZGqpa7HdGhh0OD1djpiNnzF7jrq8dsLZMwFyupJsogc4KzTzQQqKawC1AaQY2u3DWQTUghe9l3VJ18oqbbiR7G/AkAkV4cKs0cSCykyNIdOahpaOUA9EM9OycKAitDhguvBnqsxvzUqXQYcq7NDgHDJAod0BLNgD7fmhnOOqkvJ484WdTbiwIIIbSoLAoDigT7BCH64hMl/domw9Kz/pJjItMDHT8ML2qXwzIzBL zn14SUmI 4mM+j9yto46lq2dXpr0APEMiNPiRee8eyp3qMUpJ9Qk3UAy26hNdertyBpM6JlBM2WWluSQfOn7E4yjERWrPdbeNrI9kZXIeRWxSjYhzbaD4ywTBe+nyDMkxnT2CzYMgKa3GbRBB1azyNj8xI6VWfx/XyxfQpzt2IkHAiqi5pIV9C1VUnferR4TLo347VFgOIY8qTDW7jBEr2e4yT3n3j+Hw1G8pGbQKVn8Q96dIzvtKQjo0zGguc4mdutLsTciYp7e/HMLAhkOaIawrnpsEgv8ulCqMUTiA84oe0X1vJU/gyMwkPbacxv/Ehwn6p+VdG8gd1SXaZ4Fb3pc+/8zJslu0J99kHXAFkh5Tc/ZLDIrK4Oo/KnsqcFlFduhY/8jCN2qX6qu4yNhBCVM4oQK/9U1k8ewhQd4L5343cRCo6rKVxf1oA1P/dYUCa9ZdWyghgInasg/qvbJpRXVtjew5ktRBNlC2f7i6tcTtHPcg8xWSaM8rPklYJb0LBFyBti8l8rvQMGaKp2yKpp8Joe4EcEBAhxBU3dbH9/TOSdNtNb3O0Wpuh+bYbyNUmYg== 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 Mon, Jan 22, 2024 at 7:49=E2=80=AFAM Theo de Raadt = wrote: > > Regarding these pieces > > > The PROT_SEAL bit in prot field of mmap(). When present, it marks > > the map sealed since creation. > > OpenBSD won't be doing this. I had PROT_IMMUTABLE as a draft. In my > research I found basically zero circumstances when you userland does > that. The most common circumstance is you create a RW mapping, fill it, > and then change to a more restrictve mapping, and lock it. > > There are a few regions in the addressspace that can be locked while RW. > For instance, the stack. But the kernel does that, not userland. I > found regions where the kernel wants to do this to the address space, > but there is no need to export useless functionality to userland. > I have a feeling that most apps that need to use mmap() in their code are likely using RW mappings. Adding sealing to mmap() could stop those mappings from being executable. Of course, those apps would need to change their code. We can't do it for them. Also, I believe adding this to mmap() has no downsides, only performance gain, as Pedro Falcato pointed out in [1]. [1] https://lore.kernel.org/lkml/CAKbZUD2A+=3Dbp_sd+Q0Yif7NJqMu8p__eb4yguq0= agEcmLH8SDQ@mail.gmail.com/ > OpenBSD now uses this for a high percent of the address space. It might > be worth re-reading a description of the split of responsibility regardin= g > who locks different types of memory in a process; > - kernel (the majority, based upon what ELF layout tell us), > - shared library linker (the next majority, dealing with shared > library mappings and left-overs not determinable at kernel time), > - libc (a small minority, mostly regarding forced mutable objects) > - and the applications themselves (only 1 application today) > > https://lwn.net/Articles/915662/ > > > The MAP_SEALABLE bit in the flags field of mmap(). When present, it mar= ks > > the map as sealable. A map created without MAP_SEALABLE will not suppor= t > > sealing, i.e. mseal() will fail. > > We definately won't be doing this. We allow a process to lock any and al= l > it's memory that isn't locked already, even if it means it is shooting > itself in the foot. > > I think you are going to severely hurt the power of this mechanism, > because you won't be able to lock memory that has been allocated by a > different callsite not under your source-code control which lacks the > MAP_SEALABLE flag. (Which is extremely common with the system-parts of > a process, meaning not just libc but kernel allocated objects). > MAP_SEALABLE was an open discussion item called out on V3 [2] and V4 [3]. I acknowledge that additional coordination would be required if mapping were to be allocated by one software component and sealed in another. However, this is feasible. Considering the side effect of not having this flag (as discussed in V3/V4) and the significant implications of altering the lifetime of the mapping (since unmapping would not be possible), I believe it is reasonable to expect developers to exercise additional care and caution when utilizing memory sealing. [2] https://lore.kernel.org/linux-mm/20231212231706.2680890-2-jeffxu@chromi= um.org/ [3] https://lore.kernel.org/all/20240104185138.169307-1-jeffxu@chromium.org= / > It may be fine inside a program like chrome, but I expect that flag to ma= ke > it harder to use in libc, and it will hinder adoption. > In the case of glibc and linux, as stated in the cover letter, Stephen is working on a change to glibc to add sealing support to the dynamic linker, also I plan to make necessary code changes in the linux kernel.