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 AD87CE7719A for ; Thu, 9 Jan 2025 23:30:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 21E2D6B00A8; Thu, 9 Jan 2025 18:30:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1809D6B00A9; Thu, 9 Jan 2025 18:30:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F15576B00AA; Thu, 9 Jan 2025 18:30:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D03386B00A8 for ; Thu, 9 Jan 2025 18:30:51 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 80017806B5 for ; Thu, 9 Jan 2025 23:30:51 +0000 (UTC) X-FDA: 82989510702.27.7AA8175 Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) by imf09.hostedemail.com (Postfix) with ESMTP id 541BB140014 for ; Thu, 9 Jan 2025 23:30:49 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="iS2NAp/C"; spf=pass (imf09.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.175 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736465449; 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=a18oevnEucgCDx6bBf7yHFor/s+iMuzlm6FkFyc3Lik=; b=skNsKpbyOYkffeyEOoRYIts7vzSyHSPH8vyRunIqSigtCQiS985sKcp47RgxELDeyYGlw5 J1+7drPvZ8alzTer8mDcrY9v/BJUUY1bDwdnxrnUVzu+sDYP2fN3nzBoXnuFRkJ5/A2opC qliYMMotiOYROIBbkLAVssgRCh68V5c= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736465449; a=rsa-sha256; cv=none; b=5QziFSbmo7Kwln6ourx79f3EcNnbzU3wX3F0cNcvCkoWMPYZj1V7aKejsUNr3B+KZABWRD l4Lr47ypLmbm/RPeLK/AOzaAfepmx1iAzGv5rx0uw54RhYybD0TbRWLxGka6GRSqlv7oPt BtCGxbOpyIXivv9LPi2oF44Ql8TnaZg= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b="iS2NAp/C"; spf=pass (imf09.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.167.175 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org Received: by mail-oi1-f175.google.com with SMTP id 5614622812f47-3eba783ec88so190279b6e.3 for ; Thu, 09 Jan 2025 15:30:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1736465448; x=1737070248; 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=a18oevnEucgCDx6bBf7yHFor/s+iMuzlm6FkFyc3Lik=; b=iS2NAp/CDiVypDfXkk9WRpkEzwDcNgQtA04CG6ruoQ78UO5MI4wRSVn30a4RZ8o6yj ZeISW63q3xTWRW1fFUqSUN31ZumOXwQDuJvy4Lm0H/h09FKCRnhCO2ljtMU97QAUeJ6V 9q2OKYXB3iUWpn4frdzUcq8FBrXO8BzhNU36w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736465448; x=1737070248; 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=a18oevnEucgCDx6bBf7yHFor/s+iMuzlm6FkFyc3Lik=; b=DlW789t6sKrCYQAaarky74PK1aU5Z4A+THuu6VwXtrz2dCiUz6Mr406AOZiTwY9gZ9 Rk2gHHuOUmvxG9b8ulNm7L3YMf85llgdcpRkl4kIsiH+xCe954p3ES0FUSDaGJNxNB8K BixNcDqKPn+RntiS6w726fWOoJKc89nOd4eB9O001XgJhq2tu9aNgseSn2At1x9gIGul xxRf/pm1oHPDcA/eFTdR+mL+nLlqH7rxml7XCVx7P2eM31sVwdb+WK8o/M8R1STPtt69 7LvSbsQCcPyHEN4i5/XGXflJQPVsXOt7yoolNZlm9JEVDJrNV5nckwC6Qcjl1pPlHyBh nH2A== X-Forwarded-Encrypted: i=1; AJvYcCX6/I5PhT8/DCOgc11Uaf2KdmkOCmAJMePDIV4vVfcHEkhl+jLUuoX/laMD8JdTqZaVIqJRTSO3+Q==@kvack.org X-Gm-Message-State: AOJu0YwKH3eS1HX8ZnOGG4/UseW+K9bcuAwKHfI9YcLvD57d93Gjc2jK fgfl3shJYDXkSedtJ2VYDTBXLrkGO+fr7qFAOZV/cSXKab91FhYyUfiQQQsONSJvChwO3drWxkM W7TfqO6oxGnR2HIuLOwYvUlo/6OIJGxf4FVfL X-Gm-Gg: ASbGncsKtIwvVhZ/lnEasArTV8dfbH+GlQawB0GWwUOSDZRCGz3hcjs0svVHH+y+3qr UVFI/VdUpQ3HmXR6jyvYolJ7Xi583OFR8bNNTXzyP4ZXbKCTmfMo++WkaZMytvZEPotkjwRE= X-Google-Smtp-Source: AGHT+IEzileaiSuyqihvKvLEPVBKwZNLmUlTfSZtcNAalK8SQS6cuyRBZqK/FZwJ0UES4ILr+5ux06GeHIfQZftSFQM= X-Received: by 2002:a05:6870:2f09:b0:296:c3e9:507c with SMTP id 586e51a60fabf-2aa068f2745mr1715691fac.10.1736465448237; Thu, 09 Jan 2025 15:30:48 -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> <202501061643.986D9453@keescook> In-Reply-To: From: Jeff Xu Date: Thu, 9 Jan 2025 15:30:36 -0800 X-Gm-Features: AbW1kvaedR60IMurOyQMRhonOrvU2ElsItuQAytr0oRgCxIGr2Lw0F1I98J-zKA Message-ID: Subject: Re: [RFC PATCH v1 1/2] mm/memfd: Add support for F_SEAL_FUTURE_EXEC to memfd To: Lorenzo Stoakes Cc: Kees Cook , Jann Horn , "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: rspam02 X-Rspamd-Queue-Id: 541BB140014 X-Stat-Signature: 17dh6ni6tci3hfmaqboodws75trfunxx X-Rspam-User: X-HE-Tag: 1736465449-745522 X-HE-Meta: U2FsdGVkX1+YQCOE10rUSwlSNxP7X8fk0GmyrJ/P0rNZdySPokTUDiztUwWtx+XB0jADnn3BldBx6aM+oShV1bucbAsiAFWu8RStKGxyM8McdXsZ6zqL1II8cXKdr1E9GeIZkhFCaJkNiI54rZshJqQ/nUYUfmwzZWqQiANwotlM9UucNtNYY3lrxywUkvoeU4eXf39ft3GnQ8myjZHi7VQeALHNDLc8kCeq00wbu8yPIVc5uoTH7/KB+NPH3t49JLYT++lF1P4C2WqYt/91M4yWwyAeGphno4OzHV091GCUhylYJnpp9PPfVK31Wh4SKVTZo8AlkUJ0nxOm0h22fw3iixPjvOG70QLpKX7/I4m9WCbAUkH4xGfflieGjrauAJafVYEzZ4smAWDFnIo7inTNnjk5Q6rP1bVPsxNo9aj3u54auWLt6n+Yo9C7xQBl5Gue0PeqgYkkoOay3uskd1H1ZeHRZi7urHHkWtyo/MAMAUEdN0BbVSEoDZ0Pp4bVGNVWp96pcH7k/CZKtpohOm716BTavUbe+BTnlHxsAJy3d0aIC0qQkTBP/0eaO9ZItDhU9sQQJ9bfNL7BgAK+GN5BXBgaC36FqsXoMrBby9vGhqBBi9Qq4wNu8Lhrgw/k4ZBrh/95PAS8HwLc1j/penw8uSKzihPvgPzJJIN6ES+7OR+FHS+nB1C/dxxlWZVA0x1JmE1JgKvGTsQNZtvwahiem+AZ7S4FrbvGeG7LO0nT8WUrnPkTl1h4fAY1TMdslaiDN2tBSeO2e3pJnVjPymzl0X6riWaDqFkdwgx7QLp9vGLF149YogsO8HSsGOaoO6qHE0/OD/Ze6ou4jidkLUygSlijj3+mh8DsztbaNq1qJl5LswJ51IUR6RQeIoimTTrzD7pFccUuRXTN7tyMX6pFTcNaztaEFcTcp243iuuKF8bMu9dorSlGb4CMnpxsBH+E/EGdHe5mTm0ITr7 AXA3YiOd a+xrwasi7FwT2wRtFKoiRNnmffRRmqPq4rXRakUc5h6SF0aWgIYAC44kKU/xXYjHeXSOPmYviOcwFsR7X+ILJbStuXfx596bKukXHZ+UiQlqA3oOSpXNZLpdYxjfnlWULo/lu/o3d3JsiguENinh3ZGTFzTy8+2pIas1Qk28bUZ0rTbMukh5V0Wji5+uiKhmVeQssxHSFwCbuKCHDELdRKQxEX1UN07Z9Z6x+C3s917wi7+sYlxIMHcn/YaurJvb7Z7NdhXWmxXRSMkGFucL1U6Im4rAnHCxTi8cNrXZAGmh3eWMmKp6Cici9HYCpqfNZVPv0sKrpycOwnyheKLlcAkUk1qLou/6BAx7NG/JBYBOuLzY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.015463, 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 Wed, Jan 8, 2025 at 11:06=E2=80=AFAM 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=E2=80=AFAM Jann Horn w= rote: > > > > > > > > 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 wrot= e: > > > > > > + 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 disallo= w this in > > > > > another way but note on write checks we only care about shared ma= ppings. > > > > > > > > > > I mean one could argue that a MAP_PRIVATE situation is the same a= s copying > > > > > the data into an anon buffer and doing what you want with it, her= e 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 cov= er > > > > 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 b= een > > > > 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 re= ceive 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. That is the reason I think we could tie this feature with non-executable-bit + F_SEAL_EXEC, and avoid a new flag. This approach leverages the existing memfd_create(MFD_NOEXEC_SEAL) function and related sysctl for system level enforcement. This makes it simple for applications to use the same function and ensures that both execve() and mmap() are blocked by non-executable memfd. There is a small backward compatibility risk for this approach, e.g. an application already uses MFD_NOEXEC_SEAL but chooses to mmap it as executable, but I think such a user case is strange to support. If we're okay with using F_SEAL_FUTURE_EXEC, then share/private don't matter, as the threat model explains. This flag's generic naming also suggests it could apply to regular files in future. However, if this flag is intended solely for shared memfd, it should be renamed to something like F_SEAL_SHARED_MEMFD_FUTURE_EXEC_MAPPING. I don't think this is the intention, right ? LSM such as selinux is another option to consider, maybe it is a better place to implement this? because selinux policy provides system level control and enforcement, which the current implementation lacks. If we end up having a selinux policy for this later, wouldn't that obsolete this feature ? -Jeff