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 A4665C433FE for ; Wed, 2 Nov 2022 17:18:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D8C18E0002; Wed, 2 Nov 2022 13:18:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 388D98E0001; Wed, 2 Nov 2022 13:18:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 250B48E0002; Wed, 2 Nov 2022 13:18:21 -0400 (EDT) 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 121318E0001 for ; Wed, 2 Nov 2022 13:18:21 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id B85E1A0696 for ; Wed, 2 Nov 2022 17:18:20 +0000 (UTC) X-FDA: 80089160760.26.F3AA716 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) by imf17.hostedemail.com (Postfix) with ESMTP id 3923A4000C for ; Wed, 2 Nov 2022 17:18:19 +0000 (UTC) Received: by mail-lj1-f173.google.com with SMTP id s24so25897048ljs.11 for ; Wed, 02 Nov 2022 10:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RknuEqUoiunPXi2OLjUbhlEwq60lRe2RTsR6hdfQJ0Y=; b=RRnZ2dze/6CLhyKFhxGEw08Ckp4XwE8DWxZ0rZxAOcMdf5vdt9kUpYu0i/LLqPGehj pYwLBE+/5Qto0rQ3PGtpUP8z7cfs5Z97tOSErjIiA7F6Gr0KhuXI0VS03iRzDSRFYUNa ZtYLM10ihngzyi4eQW3AMFVgmfH2JF5B4VVzM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=RknuEqUoiunPXi2OLjUbhlEwq60lRe2RTsR6hdfQJ0Y=; b=vfvcwwwZU2L3hxvBC0Q35C2oEoYWcGeEXsw18b4Ca7yQKpWSYStcxndEoqNrE0f+wO 3U1kIYmCDYVLXlBkIbOHvW1chWam21MHPqY0NUiMLptKtoTpwxQJgm92D+PCTi2IPCJg STU/TSxm2PhW+bg1hz6SF4ccDzpgeqcbOyIvHpSl0E3sVbC20HSHUIYYXl8acmWtR/D3 /CUq+YP8BZj5CrYHX4+BNGzdLWtgOunk5qho/C9TL2NcDMENdacvAOHmOrNCI2b2lSsv PPtDtgvb79rkMAQQjGB7tqj4SXSf/a59CHnD/YmC8ZSpQGV2ltA/8su7eqp12De41Qmf pU/Q== X-Gm-Message-State: ACrzQf2gy+QrK0PkjaDbTbkOVKJfpnEjIIPX6qPeISu7/0G27ZV48tK/ ZyhFqxHxkoMZCq5SH3IZ3fZMJtpSR2NPNCIBHRS4AA== X-Google-Smtp-Source: AMsMyM7GIYG7A4ghgZ0+aS8SyddPotFMK2d1/uL5kMGl7GKycv3x9BCqeqPj62YF1UHA3B/H7CEDTV/OSueDj54yRvU= X-Received: by 2002:a05:651c:19a8:b0:277:3cb2:d9f9 with SMTP id bx40-20020a05651c19a800b002773cb2d9f9mr9918004ljb.278.1667409498411; Wed, 02 Nov 2022 10:18:18 -0700 (PDT) MIME-Version: 1.0 References: <20220805222126.142525-1-jeffxu@google.com> <202208081018.9C782F184C@keescook> <202211011933.DD0979338@keescook> In-Reply-To: <202211011933.DD0979338@keescook> From: Jeff Xu Date: Wed, 2 Nov 2022 10:18:07 -0700 Message-ID: Subject: Re: [PATCH v2 0/5] mm/memfd: MFD_NOEXEC for memfd_create To: Kees Cook Cc: jeffxu@google.com, skhan@linuxfoundation.org, akpm@linux-foundation.org, dmitry.torokhov@gmail.com, dverkamp@chromium.org, hughd@google.com, jorgelo@chromium.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org, mnissler@chromium.org, jannh@google.com, linux-hardening@vger.kernel.org, Aleksa Sarai , dev@opencontainers.org, Christian Brauner Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667409500; a=rsa-sha256; cv=none; b=4p5u/sjwh08OGLCB6wi0AdJRi0kcixDPDYo/wJD0gUC157UmpHyLwMTD0JhUXIEYyTNejp yqzu478YmBsar5x26UgV5yiWXck+s4vgfSelJUWx6bnn/MBWSbg3qmyVyiIZZ98uN25Xyw /Mwu/sQAs2AuYSBainQeFzeyl4wU0Oc= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=RRnZ2dze; spf=pass (imf17.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.208.173 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=1667409500; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=RknuEqUoiunPXi2OLjUbhlEwq60lRe2RTsR6hdfQJ0Y=; b=D+1VLL6oxPixyeukYgF8t6PxPGUNCcbcI2p+uiYdPq9k814mnFDKLZdrbvjjB32BqEF8ff /yBbcTI2PKSjUh82GuEDBeemsalXFh9V1C0eEEOZKXHhPVA34B1CMYrkSHnGwvClX22hWA WuO7JQNP3X2aj5RbbTVOcCZoC8TwyUw= X-Stat-Signature: hwdjwobpu9co9u6569ace6riryn7occh X-Rspamd-Server: rspam09 X-Rspam-User: X-Rspamd-Queue-Id: 3923A4000C Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=RRnZ2dze; spf=pass (imf17.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.208.173 as permitted sender) smtp.mailfrom=jeffxu@chromium.org; dmarc=pass (policy=none) header.from=chromium.org X-HE-Tag: 1667409499-130550 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Nov 1, 2022 at 7:45 PM Kees Cook wrote: > > On Tue, Nov 01, 2022 at 04:14:39PM -0700, Jeff Xu wrote: > > Sorry for the long overdue reply. > > No worries! I am a fan of thread necromancy. :) > > > [...] > > 1> memfd_create: > > Add two flags: > > #define MFD_EXEC 0x0008 > > #define MFD_NOEXEC_SEAL 0x0010 > > This lets application to set executable bit explicitly. > > (If application set both, it will be rejected) > > So no MFD_NOEXEC without seal? (I'm fine with that.) > no MFD_NOEXEC because memfd can be chmod to add x after creation, it is not secure. no MFD_EXEC_SEAL because it is better to apply both w and x seal within the same function call, and w seal can't be applied at creation time. > > 2> For old application that doesn't set executable bit: > > Add a pid name-spaced sysctl.kernel.pid_mfd_noexec, with: > > bikeshed: vm.memfd_noexec > (doesn't belong in "kernel", and seems better suited to "vm" than "fs") > SG, will use vm.memfd_noexec > > value = 0: Default_EXEC > > Honor MFD_EXEC and MFD_NOEXEC_SEAL > > When none is set, will fall back to original behavior (EXEC) > > Yeah. Rephrasing for myself to understand more clearly: > > "memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL act like MFD_EXEC > was set." > > > value = 1: Default_NOEXEC_SEAL > > Honor MFD_EXEC and MFD_NOEXEC_SEAL > > When none is set, will default to MFD_NOEXEC_SEAL > > "memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL act like > MFD_NOEXEC_SEAL was set." > Copy, this is clearer. Thanks. > Also, I think there should be a pr_warn_ratelimited() when > memfd_create() is used without either bit, so that there is some > pressure to please adjust their API calls to explicitly set a bit. > Sure > > 3> Add a pid name-spaced sysctl kernel.pid_mfd_noexec_enforced: with: > > value = 0: default, not enforced. > > value = 1: enforce NOEXEC_SEAL (overwrite everything) > > How about making this just mode "value 2" for the first sysctl? > "memfd_create() without MFD_NOEXEC_SEAL will be rejected." > Good point. Kernel overwriting might not be a good practice. I will add to vm.mfd_noexec. value = 2: "memfd_create() without MFD_NOEXEC_SEAL will be rejected." Thanks! Jeff > -Kees > > -- > Kees Cook