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 C2F3DE77188 for ; Tue, 14 Jan 2025 20:02:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62A096B0092; Tue, 14 Jan 2025 15:02:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5B394280005; Tue, 14 Jan 2025 15:02:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 453FC6B0095; Tue, 14 Jan 2025 15:02:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 211886B0092 for ; Tue, 14 Jan 2025 15:02:38 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 830D51A0D18 for ; Tue, 14 Jan 2025 20:02:37 +0000 (UTC) X-FDA: 83007129954.29.F6ABAEB Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) by imf26.hostedemail.com (Postfix) with ESMTP id 8AD76140007 for ; Tue, 14 Jan 2025 20:02:35 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uR2TiI9+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of isaacmanjarres@google.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=isaacmanjarres@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736884955; a=rsa-sha256; cv=none; b=FD9ClKdf5jYPcgejN++m5TGWzEaNb7nQa/8Q1VnAoyMtEtHsol6IDBA0421I2jLGN6R8N2 2fRBWQtW9pvq26SFWvAvMgogQ6GSdVwdEHGwdDJ9NPzUlA/Wf+sUMR9vjsqSrbNHaJD6oH GJ48TiAPpL6v7aB/rYiEmcMf1eoYu1A= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=uR2TiI9+; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf26.hostedemail.com: domain of isaacmanjarres@google.com designates 209.85.214.181 as permitted sender) smtp.mailfrom=isaacmanjarres@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736884955; 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=Hveyb9aoAeVizaRGg6hO7M1qP+MaTyjktW+AITDIksU=; b=o8va7FgSaLp3jaeOP/VBm5ZgEQyYmWgtJKalAD16TIg0lh3/EgPGPssSJBwMtaTB6uar6Z vNwkjUFWTgoAm1FZVz8+KGy0LUO6LrC1DQ+pn/nuSU/3W6gxnBXM7p/+cd3QaHV+s4Osm7 JY3KtkOacQj3iGWlyK9RyMIcVCChrGU= Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-215740b7fb8so224345ad.0 for ; Tue, 14 Jan 2025 12:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736884954; x=1737489754; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=Hveyb9aoAeVizaRGg6hO7M1qP+MaTyjktW+AITDIksU=; b=uR2TiI9+hM88rblwACKZj5BSzbK9ZziUS5N4lMCPllHauLrgRbi21RmyDm1mjE2oMj 92CWxJDC0AdFRmgXvxaHiSvwkpvWWQ+RLbneCD2bvG3QmCaStJGWBSIp3P9QA9s3LOGl 3La7rXj6ESVfH85dVjx0quPXEKjnW2CWakcaDSPTFQFsvggvUKd5Z5+bkB0cvn8aOngg Gg8BEOtMogV8uDuJ5WNuiPxiOnJ+k1I4SM6DVO4zMmJit0XcpSD2mBjQ2Ny/gSz+ExC5 YoYA0BnlGihoyhh6SLHPA12SLiQqcmFTbbadAGyO0EDSJTVfYhtwtqrQQrVXBFhGjli3 ItyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736884954; x=1737489754; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Hveyb9aoAeVizaRGg6hO7M1qP+MaTyjktW+AITDIksU=; b=koPSujPDDvtSdL/k07X7F0PNeYIKbMf2vwD9qukOkj1cNnu+qx0WTAie4VGniuO6tJ tK3dGjQVLBU4Dq6MIpIOcGcHGS4iM3uKnJE3b3P7MeRCcIGyRBbxbLqBBmaN8wdD0Le9 IQ2kflVMAaO0L9RFpQ2czt1qyKs9MmAQhWessqmjHUwK7CvMkzpc8lV7UHLI5RlOsjCC goSkxbGS8ADKM/GVy+B0IWc9IvaMPnC6NEKKNyjukK2cqYDERfltUIx4NB9MaaxPpUZI QSFHqx2FfqDpuZLIUWlEQAqASr0jbmr6na7lTWIsD7O6tWJmKRZ54Jetz4nGChPkeAH8 H2WA== X-Forwarded-Encrypted: i=1; AJvYcCWJvsmyTSUextL7Bs2RdUDWP6DXjQT4CMNEkINm5rcYyMI+UmEDpKC4cPtJn0cMLyqQtqx4WKgSkA==@kvack.org X-Gm-Message-State: AOJu0Yz97S62OaFMk5b7DrrOtv2MU73OWfE/71M9qGqaImim0vcO6tv3 HIHtmMg31TQO/agpx5znmHWElBS0Sr4FGMY9jHS3f/9ud5UpfDDd06TmeeiabQ== X-Gm-Gg: ASbGnctZ3r+8okfhvgTTWrJ9ZoVCi5WuNxNepf+W3CAZxjawt5AwapPCksED2VVPP+5 rSw0EaGqTBJ+pzaf02H89g4AzUfFR/AI71QxqFylJ//V1ZJuIm9TBHxrS4pZexWxWZWM4/VaoIA oiehJXGNlLu4SmiSGJRkegpjb9YSCaiiMYWKTXCTnHxby6V7c+QjBA94PWU++LXQ6OFC+FsS+D8 AxC0tn1/XJSnk0XoENc1eRNo6ePr+cHSZTRI+pSRkea75GO9tMH3+WW X-Google-Smtp-Source: AGHT+IF2bVrYRNGKz3rWLJ9cyUWL1tYn9dVWhGa+vJQWRrJrlqeZGCgalALI2l4sQJoTdui4wjYezA== X-Received: by 2002:a17:902:e943:b0:216:21cb:2e06 with SMTP id d9443c01a7336-21bf0e3165amr241995ad.19.1736884953891; Tue, 14 Jan 2025 12:02:33 -0800 (PST) Received: from google.com ([2620:15c:2d:3:5f58:5aa8:70b1:12b6]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-21a9f130004sm70434555ad.80.2025.01.14.12.02.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 12:02:33 -0800 (PST) Date: Tue, 14 Jan 2025 12:02:28 -0800 From: Isaac Manjarres To: Jeff Xu Cc: Lorenzo Stoakes , Kees Cook , Jann Horn , 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 Subject: Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC to memfd Message-ID: References: <20241206010930.3871336-1-isaacmanjarres@google.com> <20241206010930.3871336-2-isaacmanjarres@google.com> <0ff1c9d9-85f0-489e-a3f7-fa4cef5bb7e5@lucifer.local> <202501061643.986D9453@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: tinaagnf7rcr8hz1objz8jqwxzt6xdxe X-Rspam-User: X-Rspamd-Queue-Id: 8AD76140007 X-Rspamd-Server: rspam08 X-HE-Tag: 1736884955-493288 X-HE-Meta: U2FsdGVkX19xhNAU1t42cb+j7fdFshb1tgvJI+hhSDrLgnZXssROa/qxv0XHSsSHe7HwCJVIMCRTxas/F/D3/y/mTifdqT1Ke/eCeu0QWRym/SuyiREtcjsw0+Kzd3LLimJi6a9fwj6KaxDTNpnc07RH0FbI9DFzPA08ncUvRmjy7uXRfxQYiMQd012PtURfVyvyTWack78EqVlRbzFqnnv9KjxZhyRNEhhzWP+p8gTJBUiBX4xCqGV1KvJwvrdAnzBMRnfwEbga+LYaSys0jisyKzLKw1Bu3jNNTG6vIAV8bt0FhPiCQNhEsZNTcmxoxgU1/+d7SqbroqhZpDjoJx8ZgVFhUemiXtvck69Mbissip6TyXZnAoVVb70YqSnXyt0Uz83dFLzUSU3ZDCbN48hDofEak5OGct15dXxiM2g0urwYCJD/xzrPVvNc5Ebaq1VbgC849q5XkoCeOdYHdw7kNXau0FcNBUNDthUZkWv0PClvAmqpwfd+FlhEQEqZCi0LZguiGBMFc2iFNoPN0hWrDzAHPSaQnWMnaid7U07lfLzSwuDlzqYXPINlUpw+0KmYaZm58uNjhqzEujVEbPioEWm2wc6C7FTDTgzvbFOzQv4P/3nah3YItg+Qm8tFgHq14Dcx+xGLhS7pKlfbXy1JNgLqB8ugqfpodLLC6Jx7Y5FYmMAXj9kKHFwB6hkPpG0aym0qbQz12olutdKouReT/LGGtE2A6tInqp/IRaoqyICZ01LQoEvXsE1GIfdgEzxgwMCybyM/G94T+8nn0PeARMdryZF4tWgO1/SycW15AlclhGEjpWxgrDUHEmOuixjYo4VujA5tqDczKd+eh1NfjGKt4896BnapnxSj38xpx1u2alBMVEf5Ir5puWOGevub1Ec3cj0qcDfFq+Hj44eYkekyjNB3KprJ2CIF2H82khS4LSpROdm0a+Wcr+mCYIAr6Y7fRo/jVDSLGjj L6983k3p eu0aUwmG2FadNWyTupvqBVZX+TvuxhAiocUQ9AjLZkly+HOusUTWWDpIdhb+p9e2oT2fdfVmF3hBw3EVU78bpGRX3FRjF/uqTutPhQs9aHDLQC0Xp79dlu1CRO29w5yBYtPTqARL+xBkfnpxumfN/FReiY0i6PM1p4LuOBS2BAMOqqj09AGnx9wpbi+sRP7c/RuZuoZ5m16HXVfgA3k/0c0/Bf4keCHLLALHnFQZb5kwKCp3fKO8PEYG39gLsHGc7QU35yjbs8aKkgbz26GuRfGXpki6QRuDPwIQ+GA7PIlraqICkTwa3j07dgGCnhXpwFUYzvrQYHBX479IF2e9/iQOj2VAapmH4M1QdAaW6qnjZCfesQpPlGdlmau5xNGXsYtRur+yTEdlvLGqaLWYsMDpKF9ghXfxq4Qtsw5VIgcuCbdMb3VGYeFg8hg2inEKrqwJEwhiKBY8htWxaanbNMStTMUN7S+ZA90voGJWDmw0x2y97lcmRA6bMt4GZHo8i7lgeg3iOMbK1yoqaDoCMovhi+Q== X-Bogosity: Ham, tests=bogofilter, spamicity=0.156044, 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 Thu, Jan 09, 2025 at 03:30:36PM -0800, Jeff Xu wrote: > On Wed, Jan 8, 2025 at 11:06 AM Lorenzo Stoakes > wrote: > > > > On Mon, Jan 06, 2025 at 04:44:33PM -0800, Kees Cook wrote: > > > On Mon, Jan 06, 2025 at 10:26:27AM -0800, Jeff Xu wrote: > > > > + Kees because this is related to W^X memfd and security. > > > > > > > > On Fri, Jan 3, 2025 at 7:14 AM Jann Horn wrote: > > > > > > > > > > On Fri, Dec 6, 2024 at 7:19 PM 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 execution? > > > > > > 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 copying > > > > > > 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. > > > > > > Right -- why does sharedness matter? It seems more robust to me to not > > > create a corner case but rather apply the flag/behavior universally? > > > > > > > I'm struggling to understand what you are protecting against, if I can receive a > > buffer '-not executable-'. But then copy it into another buffer I mapped, and > > execute it? > > > preventing mmap() a memfd has the same threat model as preventing > execve() of a memfd, using execve() of a memfd as an example (since > the kernel already supports this): an attacker wanting to execute a > hijacked memfd must already have the ability to call execve() (e.g., > by modifying a function pointer or using ROP). To prevent this, the > kernel supports making memfds non-executable (rw-) and permanently > preventing them from becoming executable (sealing with F_SEAL_EXEC). > Once the execve() attack path is blocked, the next thing an attacker > could do is mmap() the memfd into the process's memory and jump to it. > I think the main issue in the threat model that I described is that an attacking process can gain control of a more priveleged process. Yes, having the buffer sealed against execution would prevent the attacker from running the injected from *that* buffer, but if they're already controlling the process, they could have the process create a memfd that is executable (imagine a system where MFD_NOEXEC_SEAL is not the default), copy the code, and then execute it from there. I spoke about this offline with Jann as well, and we both agree that given that line of reasoning, this feature that I'm trying to add doesn't buy us the security that I initially thought it would. Therefore, we will be dropping this patch. Thank you everyone for the discussion and reviews! --Isaac