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 DCB29C25B7C for ; Tue, 28 May 2024 17:14:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 716E86B0092; Tue, 28 May 2024 13:14:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C5ED6B0095; Tue, 28 May 2024 13:14:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 567146B0098; Tue, 28 May 2024 13:14:25 -0400 (EDT) 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 350026B0092 for ; Tue, 28 May 2024 13:14:25 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id DF5A7160442 for ; Tue, 28 May 2024 17:14:24 +0000 (UTC) X-FDA: 82168453248.27.5337638 Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf26.hostedemail.com (Postfix) with ESMTP id 142B614000A for ; Tue, 28 May 2024 17:14:22 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=PPrQ5m1r; spf=pass (imf26.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=jeffxu@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1716916463; a=rsa-sha256; cv=none; b=ukp/1jvklCpNeZ02TN/wITZJ97jSGcTt8Gib2XdmwU0EiuofqRH+cEzR0K2E3olxwX/g82 EwxNQ5o3cBSV3qw+EIOazppT/INuPVifTwVxodmg+a8vCGOI9yL045mgeXjyptoErDk1QO q7IH4HqpTIy6AuJVj1sQHbibZuWLMXA= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=PPrQ5m1r; spf=pass (imf26.hostedemail.com: domain of jeffxu@google.com designates 209.85.208.47 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=1716916463; 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=sT1TXK7ZG2RZ0EH6nVas07ZfsjkH1/Dt6uPqSJeUCoY=; b=hM7VrdqW9MGyR6OftUyGNSxJSrZR9o6MJIck5DuXwzQmsePpL6q25TaEd5f8WuLlag74ZT maSRDEPrwcLRU8Nx0xaqLKXDQ0OVaJDLWWv4oXOEFWFpNdBPrAjJCl+znTGbuhaWcw5DLf KCG4K4FsCD7fPZ/XQHoCXvYG7j7jB5Y= Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-572f6c56cdaso1038a12.0 for ; Tue, 28 May 2024 10:14:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1716916461; x=1717521261; 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=sT1TXK7ZG2RZ0EH6nVas07ZfsjkH1/Dt6uPqSJeUCoY=; b=PPrQ5m1rgW4HbaJgxzPxdXsZowjKtTU2cXgvyk+u6+T67ugRZCwCq9EjscSV97nlVp rNgy9Ku4OOl4Ya3+raEG6r5r/LbDfNjfxU7xJ9G4C51E9rOlb7/hjDmDmbI9m+/DC1MH 4euAcTtslAia9CfvxpEsPAQjXOeKWOhVI19ZHBCLC/R3l1dQWcRJNyrG1lDSCnPrYNWu 9u/ZbngBcm0ytx5uhv2gduS/+eiU4eyb5ken9OS4oFdqW0Wdf5gb4GfpdEEG08p3Tgjr RL7PO5zVXEbVqM8O/PiK1N+nMalLLjKaoopTK0atQd3iT17jSfWrP7zNq6jBvNwQ6qnR C2tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716916461; x=1717521261; 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=sT1TXK7ZG2RZ0EH6nVas07ZfsjkH1/Dt6uPqSJeUCoY=; b=rdNPbB4LCO8sYQbMSVBic9i1MMdX8XcoZTwVREvFfqntWhvwdR48BT9AyMBUPPWw4h WHH5oP1lwDrjc19Y4N8AqKvXHcRtcgf4KnhlLXRzYoDDUdkj6wAoATfrfmqsNAhnVC4F SJmavuSQk7Ezp4G0dy/q+2EbzybzYtrqsJjWHoem/KCmf6d8ub47xWPV373W7qWt4TZD pS2dAqs7teURYuyflgrLbl5D1+EYTyT8LOhbjOjK3AAJKAefTz/7WzNod9LXx8F5H/ia lijj/w8WtrXW8moZy9Psalzg0QC1yNOCc9PkAgFWl8OWnNUMldFB8ZjAub2WxLYz7/o0 uaTQ== X-Forwarded-Encrypted: i=1; AJvYcCVePEd3LHc1ejc+JDLpcRgvNGJvOQzyocNXlCUg6fBmm1o9grhPYMOtFIFhmN/LJsx45PR+Rg9AmOfyejAFauP6sw4= X-Gm-Message-State: AOJu0YzCyD1fpaYTlmMFEdejoSt7Q3BK6drj65fShzCRTodz+7anDnvC 3jfBFGFKR/g1QZKsQdbMnKUpYPNjiM+lWlwX1v/NT7q/gc+V21HYjptCXyZlVrAK7+UlWzc+BhC zmZrmseH/M8yyT+HLQ8hJEAWDIFdEUsCRtxUI X-Google-Smtp-Source: AGHT+IE8Pz/iLsw8edvmphGKBIzilffR3JGLP31yHX57EFk3d75gUAm2eWXqD2JVdGL2QbquNMg1y2tNWJ/UYY3WYA4= X-Received: by 2002:a05:6402:38f:b0:578:4e12:8e55 with SMTP id 4fb4d7f45d1cf-57869a07e68mr453327a12.1.1716916460427; Tue, 28 May 2024 10:14:20 -0700 (PDT) MIME-Version: 1.0 References: <20240513191544.94754-1-pobrn@protonmail.com> <20240522162324.0aeba086228eddd8aff4f628@linux-foundation.org> <1KDsEBw8g7ymBVpGJZp9NRH1HmCBsQ_jjQ_jKOg90gLUFhW5W6lcG-bI4-5OPkrD24RiG7G83VoZL4SXPQjfldsNFDg7bFnFFgrVZWwSWXQ=@protonmail.com> <08450f80-4c33-40db-886f-fee18e531545@app.fastmail.com> In-Reply-To: From: Jeff Xu Date: Tue, 28 May 2024 10:13:41 -0700 Message-ID: Subject: Re: [PATCH v1] memfd: `MFD_NOEXEC_SEAL` should not imply `MFD_ALLOW_SEALING` To: David Rheinsberg , Jeff Xu Cc: Aleksa Sarai , =?UTF-8?B?QmFybmFiw6FzIFDFkWN6ZQ==?= , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, dmitry.torokhov@gmail.com, Daniel Verkamp , hughd@google.com, jorgelo@chromium.org, skhan@linuxfoundation.org, Kees Cook Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 142B614000A X-Stat-Signature: 7bnctwyrpmfa73t389i6xm7t7fkfyu5y X-HE-Tag: 1716916462-780854 X-HE-Meta: U2FsdGVkX19pDYq0C+JzsxzA8+mKdLPpt0hRX/In5eCdD/TPocgqnMUJWSOHCIMuui5rqkHr0DUCnBCgpWMroyn/saF3vWMED4qYrtmW+SL9VXxFgU9DQet2O8teedxmWsbooGCzYYJVVXxbap/g0qsTBZZjE6y3kmPr8d508PGglO/QKG5KwKfARklTfn3hYJUjAB9QMhwsF4Jbw/dMSlReUf/HviW4hCQblM9LNQV87K+mr31TCXMtDssRlMMBkPKXXVTSOSsS66aLzRJptqwPMb86gYJDm5SebNDiV/1vpwLLQcJSotVO0jEKBCfQJDxXULM2y5bhC55D4d6g5CItxS7EDlSZtCgcIjsnpx1bn41wWZibfGh28mFRzZ/CfG12wmBP3UyWH3WzexCSmSDpsQ35LcZRB9zjZwro+OLuhCQo+Eia2hAUyjhkK0vmNGeDEzXC85m3N40NzKESjgj80FKwVh/TorJtQd2Ib7b5uaJ/4Vjvr6BGyPEsQwhj6MFooVIOJrsx9pzFUFuCdY3Kt/U789kUYhpQSIk9DHSb+8cbMVFvnkowsKrrkpDQWOPFZGMj6BgstavGDZI1LbSLYRZKqieunoJ4ZQGwDsNrfquP8SCKu+OAWrO1dtsKozhJM3R3iFi4OCzrvogd5D0D/zQisZsSBmKeXafA0upd5u11heUDeobQWs9ZI3XRyXp+P0D3JGlLgw0jNHbEcOyqNhhELJdFmP5H4N4pYDauMN3K7lcq7didjQyv7RXRMd5nhb6RQ8bbP8lrxuRTpfd6mZDScsiVna1sGnUL7xzz2REGzA5635LJueY+kCy8CUSG6Rcl54USlvmkg/h6AoDl/ETzIPA44zW7qiG3CTP0o143d4HAtRTuC+5xN1mUsxy3LF+ErJi3eEU+IZPvnOMwfcYbwvlRTQIKaPiRe9dBWXI3TMJMNQftMqwTmFY7chFwv7PuMAfo0RYCEP4 1+eN/EJo jtIgotLFkp6Ph+SratVJX0sEiyBqawHOgN5u2UplAtCIHzX5eqo48mxpx3Fr1joKt9/oUciCly/dG12AEMCsKpIMgjMaDITkZETc3HgzZcGVAkuUFnFRA3u8zdVwGi0hbTZDlOlnQu7c6tvriINUf2s8sZ6fD/2f/3a18dw2CWFeTXsVWOA3wNcp/26szqBj8X2QHbUPMXlX48Q4+GkOt5Yb7bBc0X/18YtzCMVoKhM8MaRbBpr+0ZKb9uzLG3e/OiQuVtXrdObYmhBMZcFjkJPr/zkGecwl/vr36C4n4AWQy2OexqXWuU5D+IAH1utk6oIZDhpDHu1775BSH5SVdBQ02TSOnDq6VuMHmQAUN5OlZRBe7lIoZNUYjYfXUdsHL0BQW1MVcP6mFj7/YbbnVuSJordZYFQ0FNccbB50FiqzrOPY= 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 Fri, May 24, 2024 at 7:29=E2=80=AFAM David Rheinsberg wrote: > > Hi > > On Thu, May 23, 2024, at 6:55 PM, Jeff Xu wrote: > > On Thu, May 23, 2024 at 9:20=E2=80=AFAM Jeff Xu wro= te: > >> On Thu, May 23, 2024 at 1:24=E2=80=AFAM David Rheinsberg wrote: > >> > We asked for exactly this fix before, so I very much support this. O= ur test-suite in `dbus-broker` merely verifies what the current kernel beha= vior is (just like the kernel selftests). I am certainly ok if the kernel b= reaks it. I will gladly adapt the test-suite. > >> > > > memfd is by default not sealable, and file is by default sealable, > > right ? that makes the memfd semantics different from other objects > > in linux. > > I wonder what is the original reason to have memfd this way? > > shmem-files are *not* sealable by default. This design was followed for b= ackward compatibility reasons, since shmem-files predate sealing and silent= ly enabling sealing on all shmem-files would have broken existing users (se= e shmem.c which initializes seals to F_SEAL_SEAL). > One may ask the question: If shmem-files need to be non-sealable by default, does memfd need to be so as well? > I am not sure what you mean with "makes [memfd] semantics different from = other objects in linux". Can you elaborate? > The memory sealing feature - mseal() went through similar discussion on MAP_SEALABLE flag during the RFC phase, but everyone doesn't like the flag, and it gets dropped. The feedback from communities for MAP_SEALABLE were. - such a flag will slow down the adoption of the feature, i.e. applications on multiple layers/libraries must change in order to use sealing, i.e. time of construction and time of sealing might reside in different libraries. - Deny of service attack is likely not a concern, the attacker that is able to call mseal() can probably already call mprotect() or other calls and achieve a similar DOS attack. > Since `memfd_create` was introduced at the same time as shmem-sealing, it= could certainly have enabled sealing by default. Not sure whether this wou= ld be preferable, though. > I would think making memfd sealable is desirable. Probably the same for a shmem-file too. > > Another solution is to change memfd to be by-default sealable, > > although that will be an api change, but what side effect will it be > > ? > > If we are worried about the memfd being sealed by an attacker, the > > malicious code could also overwrite the content since memfd is not > > sealed. > > You cannot change the default-seals retrospectively. There are existing s= hmem-users that share file-descriptors and *expect* the other party to be a= ble to override data, but do *not* expect the other party to be able to app= ly seals. Note that these models explicitly *want* shared, writable access = to the buffer (e.g., render-client shares a buffer with the display server = for scanout), so just because you can *write* to a shmem-file does not mean= that sharing is unsafe (e.g., using SIGBUS+mmap can safely deal with page-= faults). > If the other party is controlled by an attacker, the attacker can write garbage to the shm-file/memfd, that is already the end of the game, at that point, sealing is no longer a concern, right? If the threat-model is preventing attacker on the other side to write the garbage data, then F_SEAL_WRITE|F_SEAL_SHRINK|F_SEAL_GROW can be applied, in that case, default-sealable seems preferable because of less code change. If the other party needs to write to shmem/memfd anyway, then maybe F_SEAL_EXEC needs to be applied ? Thanks -Jeff > Thanks > David