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 1F16FE77188 for ; Fri, 3 Jan 2025 15:14:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8EFDE6B007B; Fri, 3 Jan 2025 10:14:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8A0786B0082; Fri, 3 Jan 2025 10:14:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 767426B0083; Fri, 3 Jan 2025 10:14:10 -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 5A6886B007B for ; Fri, 3 Jan 2025 10:14:10 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7A271C08F3 for ; Fri, 3 Jan 2025 15:14:09 +0000 (UTC) X-FDA: 82966484664.26.FD5CB3E Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf17.hostedemail.com (Postfix) with ESMTP id 2B2D240015 for ; Fri, 3 Jan 2025 15:13:27 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=1veZ35NG; spf=pass (imf17.hostedemail.com: domain of jannh@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=jannh@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=1735917212; 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=Vlyvq3AxGGQPA6vuc5Dm8BwxgLPTSqsUU1yRCgwYOBo=; b=J/FXghfCi/LaWdA3T55ryqCPIs9kr9s6NNWvBmLCbu4xROfvfyvErcMbAv44zx5FJVLAxm NPnF+KhePmIBfWcYBBKBugMqZkMFxvUw2KkGXoDXhBl6o1rL8XkyODJmK0bCm+xpLxOzZR DHI3gJb6hIAGUU2P0VcdjuyzqxeP4w4= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=1veZ35NG; spf=pass (imf17.hostedemail.com: domain of jannh@google.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735917212; a=rsa-sha256; cv=none; b=nSsXzRMlO5QYVf+DTJAF/b8XAfG1rrzgaLHszwUeLFqgDq3deHYm4Dtzrun3gg8B0y7sBL sLLr/tdP5qs1c2dfJ/rkFfuo5oHotye8ZaHYSGq0hnK/sxmkapULzqxAx3bE15sp8bpa1F SaocszIB3eXiQJuFPZ+m1BYTD6EINAA= Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-5d3e638e1b4so6372a12.1 for ; Fri, 03 Jan 2025 07:14:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1735917246; x=1736522046; 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=Vlyvq3AxGGQPA6vuc5Dm8BwxgLPTSqsUU1yRCgwYOBo=; b=1veZ35NGRoZcxOnixOo48ign7XZPcUXkj9ZQrZO4P+KztY5JzQv9zL2JZdHWetFT8N Rskc/I+SgnNxKpfQowm6G8xza+pNs++DTd4uv7+ZV9IvbrF3nV9MoVx5IhmLx5sqQ9nE 5SqhsruHl/PULaOPh7vG2d0YWP1rcUXqhk41AlTXF+DSWdEm95WTQEOYW8BdqmnS0/wW ktqKJnJLnB2NggItO/cqW9kZPh0m1AQnaSwoLHqgmzRmdxDsu04HOU9o1EvoyYz2RO9G Zwq6thQyxIpovdd3rhsAGIcsyCV08I8IghRBDwV+RUAVsxd05BxVSckTNaf8jMUN6iru iu3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735917246; x=1736522046; 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=Vlyvq3AxGGQPA6vuc5Dm8BwxgLPTSqsUU1yRCgwYOBo=; b=Z+wnJr3jOUFQc3SIBz1uZl+JWYiq6twiDYaZhYGMod+//CNNC4yQ0CyvjrzEUXPWbh eZVDVB3WPaItaHS5vPwfl+UMsUvtYzJna7ijszlYhq7U4yZaTSEo/CSq5PvrQwpztE3M opxWWY5gs4WGzUeuo2+292k9EIbwZ5o5JGfxieV//1MeVgKYk64cUIsTClcHg4S7YbG1 BRctyz6X4BDJgLay5lT/1Y9zfcf5yTXAsseJIhCtDR8ODoMIvNa9CVXRckPnWqf5SK/Y PcnEb0HjAXdmO8Ii3/5K13r6pKsbCAmBBS0urefMvPEDqYi4lTMf+y2HV03PGMk5ewWx bo1w== X-Forwarded-Encrypted: i=1; AJvYcCXaQ2gxzUASkNHXiV+46u937f0Sth7x4PwbsonRyOvg+IKjVsMxiBVP6pRm5DQrNiUsov30qs/nSw==@kvack.org X-Gm-Message-State: AOJu0YwNPm7vHf+osjZLQ6U2q+wmFu9sehy7HYdAjUmZQJ8udLlQLfIc mKKYO32US24IXEXlq5lp2ZWbbgUC5NuzolKcOYLDqa8MLpUZo6WyiwcMg540nFPRvAgwo6eR64I dIUKfeATw4Si08NsPeWQqAN9cNBELXlo0j3FK X-Gm-Gg: ASbGncuDBXMGTMiQio8+gm1I0LTd22vEU2moJxQP+VzXDaf4ObSPEg3SsqvdYju61Mf JHAI7TVGS1NG1IO6bz1xypxIHB/dAPsjl7rRGQKYft3GDLBU9nWHtOEF8NXS6hrgNuA== X-Google-Smtp-Source: AGHT+IEE6Z6Csv7Y7V9KFtLA++eWInL/BGHjLilU+NVh+pF3/5irTnuBYbk+Tu1ZwwcGEkuXZWEwDwgvaupqQBCYKic= X-Received: by 2002:a05:6402:538b:b0:5d0:d7ca:7bf4 with SMTP id 4fb4d7f45d1cf-5d9156e2c80mr71517a12.0.1735917245511; Fri, 03 Jan 2025 07:14:05 -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: <0ff1c9d9-85f0-489e-a3f7-fa4cef5bb7e5@lucifer.local> From: Jann Horn Date: Fri, 3 Jan 2025 16:13:28 +0100 X-Gm-Features: AbW1kvaGhgvt8h3xpCBpboR0oJNSmluhuHWn2o3nP9fdHRR9QmflBGC02PQRZsE Message-ID: Subject: Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC to memfd To: Lorenzo Stoakes Cc: "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-Rspamd-Server: rspam05 X-Stat-Signature: tn6nprip4cprp79eu1bb9osxo5r7y148 X-Rspamd-Queue-Id: 2B2D240015 X-Rspam-User: X-HE-Tag: 1735917207-735533 X-HE-Meta: U2FsdGVkX1+NxRvnuWtwASg+Gy6MlGgs2iMW759zCw/uGCfZpCidZApXkcmOQjaCCMGz9mB0QmWkY6871/4bvacT75U9fT+bhIdFd1E9+6Hfr/vFV34e1eXMsaGdGyjx2hpMAaYrZNYdIKKGb8aGh3b0kf3tn9YUff7Md9fS0bN6FPfYdvB3lA8X9nB4Gp/mMkfPGUzB85E8x0A+pw57QXbSLILYr94dWmPFk7zTFHaw6tpQ5wMaXoh4l7tuQ/htWP3N30xMdHT6b0GVir88DykZmUHUXgVkTo3X881i+0Q5rSeYC0hr7seGj8uKmmQb/94Ewja7BvujLIZhDauYaGCKazNelSi6UJNVAYpSi9nhrfPRdH7Cr5o3a8OPJSKyD4kHEafDKqvH1hc5zOfFSgkqpUVn4sdYh9PrqVfPnZpN66NQJEEMwpm0bgrYhOKIBBF9aMtrKUpuBwXo1Erb18Qj/+5SSmwG02JG5hY5QyuTmxmuMrXCVT34fQ369fk9AY4hhs1Kw3wgkK1OXefHSgdUddyFdhNTQdsFnItZL05lykW5/2eKn8pa8ZzMe/3NvH/7HBTgftWQNyYFA+DLtU9CFRTXBChLXLfR1uNKzqCLyf/3+njVXUiVzsUZYyPXGJE56Mkkxx6be9xHij9ju4XT6aoUCS3xaojygJCBQlTHSw02CbNxTVgsIbjx0kAgEwr/UAkH8dgAG3dxX3qc3Hgnq1yPCUZHt4YZzREka0dDJApaWe1D5/W9UCP7xHzAbGiODwUnGvspo8bwxz2VyOENvvcOGbnGimMZLW3WukpZHZs9E1FALxudFUWXdKHlbv7nDEUq5UX1ur1MBByd7n70zjh1pi2wpf52ayI65SsXBLwmLG70+nKfIxilYBbSVxYKwjBEzApgxWXwH0kek6yVYG3WpwlcV78/n4KxBw51+hBnK69oOoZ+2vNlib6NSgxI+B2YlX1irOjnNkb uV9hMY00 kDOm7afVjaeBY2pSkp0iwI3pJfq/obamKt1pNQDbY1QrcJ2T2A7FnwiHoVyhL7JVj25DOSv+CzUWTnqjGbIsLhDjXwV/zB21zaJY0YMtpEbj11Z1rJl4vdY1q3jKNRyt8JUN9TDXTAjJtjR8PMSNhlXQ7/S/uxD3+0M3jjO+V+8dIIp7NjWutdOXMXPsv3jxSBuiKacK4twL5HcFxTXLYIQk6viUInMKxv9iXd1NhomZXxE3ULzql7jil5p/5673IyGSjohBe4agSOMZU1vbcT//Ji+84eMpxGfiWozANH+/4yGNjdJcE6TuiObeg8jiIVacBY7jq85ficXjyMq/3oNMZdw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.410800, 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, 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 executio= n? > I've not tested this scenario so don't know if we somehow disallow this i= n > 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 copyin= g > 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). 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.