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 A3FFDE77198 for ; Mon, 6 Jan 2025 18:26:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25E206B0082; Mon, 6 Jan 2025 13:26:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 20D806B0083; Mon, 6 Jan 2025 13:26:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0DF7E6B0088; Mon, 6 Jan 2025 13:26:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E3D6C6B0082 for ; Mon, 6 Jan 2025 13:26:42 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id A867B1C59A6 for ; Mon, 6 Jan 2025 18:26:41 +0000 (UTC) X-FDA: 82977857802.24.FBA8482 Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) by imf28.hostedemail.com (Postfix) with ESMTP id C976FC0011 for ; Mon, 6 Jan 2025 18:26:39 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=TfLFbKRW; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf28.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.43 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736187999; a=rsa-sha256; cv=none; b=jxsVbcHBdQ+M04YUdqYCZ6uHx3vp1UiO6n2SjkP0jQIjda7ygl5pmcUWohQNxBFXk2Ota9 jNxqZNC2Btp7EBQN7Y5RPQJ9kfkFtwuDsE1Am8xO+aVo1R7inezVvOHMI0acUWBgw4O5wQ EM6zydu5xm8VSPHrFkxkXkXQLupzRQA= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=TfLFbKRW; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf28.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.210.43 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=1736187999; 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=jXrSRS1etO43ivLqxy6UM/j2BEkIv6LJbbDAsPExvN0=; b=OBd/oFHceS5+usrgIpwLOjQMXvG9WQB5uv/LbLQ+Bk5gaskdvg+HDb4opd53QTj1mA7HEF n7tGTXkYUL8BxOFw00qadhOzUjNEbGe4FRiybSmfzzfRu4iiKkGiRlg97gdKkmiFWpXW8Q GJqiaeYOGe63BFQPBfuM0/3yXVNY4W8= Received: by mail-ot1-f43.google.com with SMTP id 46e09a7af769-71e31d295eeso1198319a34.3 for ; Mon, 06 Jan 2025 10:26:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1736187999; x=1736792799; 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=jXrSRS1etO43ivLqxy6UM/j2BEkIv6LJbbDAsPExvN0=; b=TfLFbKRWzeeLjvu4gmLAGpjpTzWS5PNDw+nYAoLvKNtsvCAskyn1IBsGaHDa8UPiB9 AliQ/AXB8TbxfuqsPSYQrd94y7aiAwUKEkY+20Jc89fyyWhUPeIlvO6juQCmX8Q19TFT DyeVxWy//Y56YSo2DBxnWdI/7cGI/Jn6IAGrY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736187999; x=1736792799; 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=jXrSRS1etO43ivLqxy6UM/j2BEkIv6LJbbDAsPExvN0=; b=NupUT9eDJPNHJF9m11nLoG9BMI7+5JKJAr93LSMtGSr754V0Dn0TSCB4wbGBEEQ6XU Ow0BslrWwRwc5JU27HAnquIzR0n+4MyyCWF3ti0Xz3gLevm41ZS1fKXz3NypcAqG0NRw WNbPA8uXRHYh3W89JhcgvHll6IP8Ff9KE8wk+Ncl5+/5EoWtEVIPYaMlR6/WVpiNDy3G OMrQwV2hCouSR2q9VzYLWStbHe+TIOX9yT83TmAHv0Mr/ZDRy1XHYHTP7A/Fgkui2p9V rx1CAbf+EEJQQF9b5rFMuilZxpQeZ6K2ZwsWZYds/zITtnqdKSEnw/NPp+i8Zg3Wn4F1 hxyg== X-Forwarded-Encrypted: i=1; AJvYcCWP18rgxVdRIpBk4JVwT9jRdpqG719igkz9uC9NROlSgVHnyJljY5hvEfcTOU0ZUKzsMJh/K1R2jA==@kvack.org X-Gm-Message-State: AOJu0YzFG3fxoo+/EZDhCapq7UNXdKRWyL6DSOSnNi4veNC378ARYCdd ZlT5Itaa5lUkjEE/VkROC8WHyLLAkfVeYonH/5ow0nKxp5UXourM3yqCF8/Bl6DYMlH0aQmHCMx uNfnGZrTWx35KHcU7GnvTXORRbuda4RGWsYnB X-Gm-Gg: ASbGnctUlPVoKn7S5WOOBGQ56/zXYB6t/X79capJK3kSex8MPcbip5DM8O2yLm6ymh+ 5lxJ6g4WU5sV3sBL721nK47Oa5aSof4/Gd4IQZJzkWkMOFX/LKKZHLqn6GJH+M5GE0aI= X-Google-Smtp-Source: AGHT+IE8p82py8jxmMvLIqhmZwO1SpWspYcZlaaDlXjw86T5QXXTzLjS0dO5FcxogIabP7CFgtlSJ6PXzCt14gK+9qc= X-Received: by 2002:a05:6871:a105:b0:287:2cbc:6c9 with SMTP id 586e51a60fabf-2a7fb17c51bmr12092971fac.8.1736187998596; Mon, 06 Jan 2025 10:26:38 -0800 (PST) MIME-Version: 1.0 References: <20241206010930.3871336-1-isaacmanjarres@google.com> <20241206010930.3871336-2-isaacmanjarres@google.com> <0ff1c9d9-85f0-489e-a3f7-fa4cef5bb7e5@lucifer.local> In-Reply-To: From: Jeff Xu Date: Mon, 6 Jan 2025 10:26:27 -0800 Message-ID: Subject: Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC to memfd To: Jann Horn , Kees Cook Cc: Lorenzo Stoakes , "Isaac J. Manjarres" , Andrew Morton , Jeff Layton , Chuck Lever , Alexander Aring , "Liam R. Howlett" , Vlastimil Babka , Shuah Khan , kernel-team@android.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org, Suren Baghdasaryan , Kalesh Singh , John Stultz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: ruaw5bm1pkz86beq54gzg3zerat4ecwe X-Rspam-User: X-Rspamd-Queue-Id: C976FC0011 X-Rspamd-Server: rspam08 X-HE-Tag: 1736187999-428950 X-HE-Meta: U2FsdGVkX1+8hyTOsaiRrU2iGEMOSLHq9tBrdfzon54dLmbgcrdnTGUHTwL8n3JHOqzZ0DftkfX75i6wiZbSX500krGRYl7EnYa9lwSE6YzYSKyPX/e5SHpJnW0IBuQJyF8TLJ1JV7Z5T7ys9cWmphBJXefdFbrMG8PAcXFgL/CDyz1q7jL/Vfa3fq1CVHcXRt0h+FzZRYxtt9qfB7booa+u9UbIo//FCUO5MacOO2b+yLskBYab4LO+InqM4YQuU+vWAdNtvNkzSLyVp3SyVrAGt7CNygyrywckVhXyDzcyWBzttTA11jqwH8cOOuXIZCnars5ojwAae190/vooEKiYnVNH07hl5YdgANQiN4qTkuBpVmkqrP+w8vMGtSXwCessVLm2ZCFQTK4mkcppfoDiHhlM5aWKfxymewDUliCKLjTLyI7HQVzOp0oyZe/V6SWK4c5382zh/4SIW45Ud1jVGKaXwzDyA9/QVzbJY47ukeHxUJ/7JyVfelXtCyi47PAj/u0yIb9JbjmbJI5IhFftxY8sgz7PV0+YExwf92BCZebDhxNhfrYLcWeGba2eGOlGeb4nuwmt9Uph8PJn1ZT6v9KVQ3Psrk12NvHXl19QmT/D6Acc5I46Z3B/9Puhyr/ts5/vTpjW+IktgeTiJZThbPGxOLmQwD94yZXVIq7uthFYquOsYnEY3R409LaLMQTRm1iyOvHdJJKeJCKGhvdZQaVHodm/Ewl3emR7ahDXAKY6QQNQlVXMYWHI0dAyVjyGQjTva4W7ioaBDbavkFALFi7nsQAu0n4J5WBbENxsP6WRaCYSVl2FZZymhAunzjctRTV4UKMI4K9k5k0ZbqCwYKgAbqBl5XSBkWavs/qMLv4ha/Qc1urLS3yc6fhye22egUNXWzUX8rGEoWM/byRHgSNQzMi105hiQcWhPcVbRuUaDTKN4jiGMRzwGoD1lKl0G+bEFAoPUlljrhx xq/FxFVQ i/7H3yXD9Vr7tyyZBC8U5gw23Y4nAZWpEVZvA3kght/KWnhUh0puOL/wNACreywv/4b7t/YpuMFEhZeSdjVB1gKJroWxdMQHc5zAhS4CdYLCMZOIsR3QIimoGy+0zlngMqrGee5CjM+csCF36FWa//qQQ2gQJvATES2zxHwUaxi7LmOSLImT1mr715jWlv1XCRkW/Hi1pHKvnEU2TVF0AhwG2MZuBmJ4CYWGc62RQ6bS3z16r4qhkuAXD3Of5+VTBYNtC+Oph8PedOl+EYkFlbpZ/1510KsgTahtO+GQnDXaViAu15xS9ePUph2xZLV6rQmNVRJ57iu44XnEyUavwqkXwKToqlU/e3DUSD1O4yzAvE3U= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: + Kees because this is related to W^X memfd and security. On Fri, Jan 3, 2025 at 7:14=E2=80=AFAM Jann Horn wrote: > > On Fri, Dec 6, 2024 at 7:19=E2=80=AFPM Lorenzo Stoakes > wrote: > > On Thu, Dec 05, 2024 at 05:09:22PM -0800, Isaac J. Manjarres wrote: > > > + if (is_exec_sealed(seals)) { > > > > Are we intentionally disallowing a MAP_PRIVATE memfd's mapping's execut= ion? > > I've not tested this scenario so don't know if we somehow disallow this= in > > another way but note on write checks we only care about shared mappings= . > > > > I mean one could argue that a MAP_PRIVATE situation is the same as copy= ing > > the data into an anon buffer and doing what you want with it, here you > > could argue the same... > > > > So probably we should only care about VM_SHARED? > > FWIW I think it doesn't make sense to distinguish between > shared/private mappings here - in the scenario described in the cover > letter, it wouldn't matter that much to an attacker whether the > mapping is shared or private (as long as the VMA contents haven't been > CoWed already). +1 on this. The concept of blocking this for only shared mapping is questionable. > But you're also right that in the scenario described, > an attacker might also be able to create a writable+executable anon > VMA and copy into that, or map another memfd that hasn't been sealed, > or stuff like that. We can block such things - but not by only > providing sealing operations on individual memfds. I think this > instead requires policy that applies at the process level, either > using system-wide SELinux policy or using process sandboxing APIs. >