From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8E1BE213253 for ; Tue, 14 Jan 2025 22:42:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736894542; cv=none; b=ZzGSqClh0FnwRbevMKnSs6XBEoFWVRtevU1WmfXY61NKEsy2zGNbiF202mVAP0m0MTr00WWWYBWPTaiTq5S+o9BYJZZOdXG4wlrjLW2S+lWtkwjgTrI7yVc0bF3feuUW7WPJ3TluqFZxG9mll3IfocDUlTeEsh7WUFfHvcGLQT0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736894542; c=relaxed/simple; bh=Xs1dxq2fGPPYtaqU2IDeyblBvS5L0xhG1gPyp9lfs+0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KAXU8cnv/niImEzB8nhYmtTeKe7KAE6Wv7NlnrbCSLf5WoMbhDEFLtYMICC2GEkAfnHbUuM3sNwIOH01CyZDvWM36CbfuOVj67UK2R0LAhNVL0ozO0ADTi7Xdn5VvkBwoCy3iuv9otaEcFH7BwA2XHPUnGttVgDfJrCY4tBMepY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Q+LsTw0J; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Q+LsTw0J" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2163affd184so209795ad.1 for ; Tue, 14 Jan 2025 14:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736894540; x=1737499340; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=swMA7a3HQZ6EnlfLP67EfqYFg1OFOpUwx/BZEKqDMMM=; b=Q+LsTw0JnP7LfO47eHwP/JYC6wxNJsi/bb0c1zF9xc3guZzqRj+M23ZdM+nT22T+i9 h9nFLY3B8AD+paY6wZ+//ObxOZWfEmY+ObBSs7quoUmuD457gBCWsEt7LmUxPSIDnzB8 DAo6+KM+CzDcy3DkuZLrxAtE58jRI6GXOk33U3TbjvJmyEBijcabXDVNimxrSMIJUds4 Ocf+7Y8DdlVtiNvXEWePO5xDE7O835QK60gzjt7PtwfNvBxflK9kFmQkMsYYave72+0G OcJKEqw3u7gw+fmsoUexq+wnZsO9I/ttvk2BV8dblljgqLzTQkdMD2Rl7ZbOR0ddDeye s9wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736894540; x=1737499340; h=in-reply-to: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=swMA7a3HQZ6EnlfLP67EfqYFg1OFOpUwx/BZEKqDMMM=; b=BaAQu6Vg1cZQ+awS7hrzgnXqePCHVXmcuJaQQHc8QCbAoFz22QLHZrk6xE3bdG0umt KVcbzK9s6VGAT7yZjZy21kOLNCPWwllm5VNkvnixMo+DPqXNNYaKAU+BMznb9pJVWgr1 Gd55xpQvwNfYyGlRW6X0snCeO08Ng//xNrOpjt9BT8D3LzbAl5z2eKeE82r8gDRWrT6N zlRpWA1QJSvRArKLR+AmHWGKTWFHuSm95Lo0Nau3/2wL6bcNbhAnQGNXSN2dm4wXkZSu WqjSV2Ax5SZoeLk7lB0eiWLdEOrO3ewFJPdok1mU8G33VQ74R90fNBVQ81Re+S0bNxSk bkhQ== X-Forwarded-Encrypted: i=1; AJvYcCVdOEo9sL+1qsLGecj9k594Qz3J+Uog7aNHG37GyCMthWJdHLN0hrK5oyhB+IjB4mWyhdLfSShm+9V3oPg=@vger.kernel.org X-Gm-Message-State: AOJu0YyI1ThTiXEv3BqN73TAllAHnB7u9u+ZUrauGu5I2oykKXox9Ca4 D1MWmJ83N7d1+M+my+NN67IWhJVYvIYwJd+4rIDEoAiTJ5sdrq9Oo/48mFoibQ== X-Gm-Gg: ASbGncvxzMzGBEFoGdxx+x+ogHprjo58RUs8NttvVRztsfdibqSasHYH6iN5CB3Z/wC hn6p0Jr5KQEjaA2dLgTWJN4MAePaypR8iGRs6C+OmyekDzt0kbT2316Ttsv/i8qJ+fiRyfQ32Xp s9NJK7ZXyOFxF1ELHVPjOHu/7yeCUz4QqnU4fHCL3GZsvcsK8TUI5JlDz/cFCaBGy9GSMQuq+9W RipcMqJ6VIee7ErvqfH55WapT/ONXeIsMu3Fgw36ivAvvRUIc+ha/N4xQ== X-Google-Smtp-Source: AGHT+IGoegfwlqw2q5WVfOTyFF4JK79h9BcAugnc0Xv9CPqMRMnAP3WIacvl0pdW6tR1pdom6vRMig== X-Received: by 2002:a17:903:48f:b0:215:44af:313b with SMTP id d9443c01a7336-21befee6a7cmr867865ad.0.1736894539639; Tue, 14 Jan 2025 14:42:19 -0800 (PST) Received: from google.com ([2620:15c:2d:3:5f58:5aa8:70b1:12b6]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-a318e055feesm8811734a12.30.2025.01.14.14.42.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Jan 2025 14:42:19 -0800 (PST) Date: Tue, 14 Jan 2025 14:42:14 -0800 From: Isaac Manjarres To: Kees Cook Cc: Jeff Xu , Lorenzo Stoakes , 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> <202501141326.E81023D@keescook> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202501141326.E81023D@keescook> On Tue, Jan 14, 2025 at 01:29:44PM -0800, Kees Cook wrote: > On Tue, Jan 14, 2025 at 12:02:28PM -0800, Isaac Manjarres wrote: > > 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. > > I understood it to be about an attacker gaining execution control through > a rewritten function pointer, not that they already have arbitrary > execution control. (i.e. taking a "jump anywhere" primitive and > upgrading it to "execute anything".) Is the expectation that existing > ROP/JOP techniques make protecting memfd irrelevant? > Is arbitrary execution control necessary? Suppose the attacker overwrites the function pointer that the victim process is supposed to return to. The attacker makes it that the victim process ends up executing code that maps the buffer with PROT_EXEC and then jumps to the buffer to execute the code that was injected. I don't think having the ability to seal memfds against execution on a per-buffer basis entirely addresses that attack. Can't the attacker craft a different type of attack where they instead copy the code they wrote to an executable memfd? I think a way to avoid that would be if the original memfd was write-only to avoid the copy scenario but that is not reasonable. Alternatively, MFD_NOEXEC_SEAL could be extended to prevent executable mappings, and MEMFD_NOEXEC_SCOPE_NOEXEC_ENFORCED could be enabled, but that type of system would prevent memfd buffers from being used for execution for legitimate usecases (e.g. JIT), which may not be desirable. --Isaac