From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 D8F8D1FBCA6 for ; Tue, 14 Jan 2025 20:02:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736884957; cv=none; b=QYWWEjR7X02KT5ahEydsVLeD4LGCP9T2nBGfHGignF+ymL4IwTdFRqcbcmiGC7qH26M+OLdtk7Cey8pLnPW65weknRFiDPEnEwtIgsODXQAb9wZ3evIapLPwCm2jxrn+5YLLUkRQBnQgFQi4NQLkZyXr6kRdyXvl7lqAFDscmo4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736884957; c=relaxed/simple; bh=G1NWNqJ3o0Xvmg9Lzh0JSizt0ZbxBRfw6HXipcTT9GM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=T92HZcjrxjFNQDfWC8GicezpfiBEiBdA/ls36xvPnoH7EFQS4lxc4YiW9KyIh4WhNTemFKsTg6NlZQyfGcGcRWU0vPIxm+9e4rHhkBa+x7/4Vwwfaw/GmrJpnkeb4r/jAn7bCtyfbZFf6GM09rKpDtbNMCd1T7y3FyH5Jlo0UE0= 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=MIgh8ZIL; arc=none smtp.client-ip=209.85.214.177 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="MIgh8ZIL" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-215740b7fb8so224355ad.0 for ; Tue, 14 Jan 2025 12:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736884954; x=1737489754; darn=vger.kernel.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=MIgh8ZILmrms4HrmimPHIB2jU+0iDLe6t9piLQOU3pOh1/2NhadWhHKK9bVH6N4coS 5qSfg5a4vq6d8tO70BSspdST1SzvfzQWD+/lWfXtDB2Obz62QWSiRnijphTIVjEPGBce v/dsWLgJO3/zIzEFDkNp8LCClTgSbCY40Wb/mkoZw9N1KfGi/6dMJSU3/enYOTr3xr8d +Bv4IoM+0e4GiwA8h3i0Kzrj07o+3ka26yq7HogZnktqXkDvAumDgYcXfmYaL5wxamX/ Zderm1u8g1AbAt101DZek+VwKHWnkjeCbm5Wie4TXmjavk7ODVi1fkQxc3lnXZz9qcIO r3EQ== 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=AEM+y6I4+R7ar78fKmOpaIbP4hGmKQel82glgmt6ZP5YgW8cO00nsSutkMP5Myi4RU 9WJneIbF6bxdX1Huk2iJokxRcJCzul7HSPNWF2Tq1kUTWM5cp3AHfozm/grE2IgzVipA gFnETZiw/YUCrPEQsITJ5y1LtL6c5vHpdWsa99TbqNeVmsXrAo36IVJQ68h3k9G617Ks Q6gHfyHgu1aU3RL7FHeGUDnLMNdMBLhmh4xQgijzGBOnIlKb483m749H1whf/dmimVi9 o2tpWyk4Cs19joG/lFgQbeqjL/K+L2HjXZjjaeRSFotU3tFatwHXERlRpMfmFsS1ODRi D30g== X-Forwarded-Encrypted: i=1; AJvYcCX+jbwieG2zpy3jcUpIMrNK1ijMo433E3GB22ArihFPoF53z8bTAjoKp8GkRyTxwaQ48tYnBtepc7U/nIM=@vger.kernel.org X-Gm-Message-State: AOJu0YxnLETc4rNBDg7aXvfRYsZ5gKt/sV5WgwqTyZqzxgYudauIeBWk WNTaIC3Lfx1RfjmVrIt4EPC8j9Ft3o/1sp5eEpEb1vmIYlNdLWYCLm/xEJEorw== X-Gm-Gg: ASbGncshyr7fWd3SjyVj5Dr7f7tiY4P/6cCKWxnIeeDsG5+iw6WzEgusFvfIiI7LRIL CIiIk9/qskrP2MRLCFfJIBnhmNVytLQ1VOBTHp4g8cZg7TgAwlVCvyWAAmSLp21fCdEhkr+rSU3 61QlzwOT8sbnjuTtL6sAOMk/fiPig3DO2B3k5wpKfcGzxKkonADhYoXZ8bG8RR0361+n5xJQbm+ SDbV3EztGWh64kDCvFZurETmeXiFrQXKceIWIq0SWeZjMZvhc05C9c8 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> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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