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 9CEEDC3ABDD for ; Mon, 19 May 2025 21:54:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF3946B007B; Mon, 19 May 2025 17:54:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DA5476B0082; Mon, 19 May 2025 17:54:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CBB2A6B0083; Mon, 19 May 2025 17:54:24 -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 A662F6B007B for ; Mon, 19 May 2025 17:54:24 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 98E12C125B for ; Mon, 19 May 2025 21:54:23 +0000 (UTC) X-FDA: 83461011606.18.06FCBEC Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf10.hostedemail.com (Postfix) with ESMTP id B6233C0007 for ; Mon, 19 May 2025 21:54:21 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="JrJ/4FyZ"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of jannh@google.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747691661; a=rsa-sha256; cv=none; b=jP2i0zC5AHYa/3X/bAeJuvWgrB/iDVzTt4fwbBlCwhyBgS6G+SbMn83KcgiuLVH4MIl1YE 8olkPxpdazLG/wUXdQnPqS+OMLOJPWU45YYurSVdF0ruX1DBDsKcJFFq6yJUa4lxGLNAUV OgJ/Fb3LEJyWsviBKE82kCzYDXj3CCk= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="JrJ/4FyZ"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf10.hostedemail.com: domain of jannh@google.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=jannh@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747691661; 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=1cMrRrD1wKYeXbyb4edK//2QLqfqx2FamRPjULNvPhc=; b=gVxttOu49OMkS9zF3CMha+a+HquDZRJuGw3cLzaqOTb3SCOrvg3A7AhKkZf1QhlXN01eSw 1oZXjTNQOcq4DKJAu5ueIVkyD6na2X+70Qf+el9jTvv0UIGK5v6p4rZfmMJ7/lkr4IvB1M iZrWozki5UwGFYt5Ld/RF3LqIFvXsN8= Received: by mail-pl1-f176.google.com with SMTP id d9443c01a7336-231ba6da557so416645ad.1 for ; Mon, 19 May 2025 14:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1747691660; x=1748296460; 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=1cMrRrD1wKYeXbyb4edK//2QLqfqx2FamRPjULNvPhc=; b=JrJ/4FyZRHXrVhfzKNue0rr7tVRBqLOXQANzIwZpIHQlX+OGzZUH50hfTDTHD8zSo5 L+AWYos13DrsLacs5C7aOD1o3IJLxp2XH9A/IDIrN9Pytc9DfjgPCU14dUI/ZOLOl2Ij 4ehrJTQYnnZMnTpsk7zvtyutei0FMgytEGVZz9olEuKIAcjlOzshdyobB2IiTOqTdjMK Rmc0ubMY9R3BgfdXg6Im4rSMhnoSNaoItYdMGbQ1RpecPeMA1XjaYSfqq/PgB/xcc6aX vxfG6UtHdwUaCPraGshRPX6aBBJqMrhAmfzg9zCOvX3Nzp50AX/wcHWowBS0hEJ4PviO XJPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747691660; x=1748296460; 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=1cMrRrD1wKYeXbyb4edK//2QLqfqx2FamRPjULNvPhc=; b=LFHhht+uMC3zz8XFh1F/7sSML5lwbbkNaczWst7TdfcEPcIqFLvdUpewkf3uVQokeX vIrjCiXBm/h2eJLKWU+Ko767LW99msfEUDQLMfMgAiRPvxLOLcwT/I8aWoQjVOZkTkC3 3mmE7Xuka2h65vahArLk43WFgE66osOWjGoJc7hhhSBuKOLPe8OkYtRcaLM3TwV9/iVk Qij2ZmLLCCt/tjetWpZufwW9T8G8jtMEW8Hp5FbFlvpVJ0lfO4MYLA6b8Tk38g6Qp2lj WFb9zbvkWelPSq00ZKYifqApdLPjkXp5kbWCW9ueDacOskHX+GZP8XCR7xe14XnfNpzB nQCw== X-Forwarded-Encrypted: i=1; AJvYcCXyQvZs+4+fYtZfCx62Vn8OnTjlXNpUjKvfl28S8Mo2P/ObYHRdJ3DRojSwFqRAOr4QLTPqv1IYHg==@kvack.org X-Gm-Message-State: AOJu0YxRCha0nfRJQzoOgiwW/aRfz80y1I/ShKqYUINoFV5VQs/kQwmt YgYgcehMoc+CpcBPkSkrk47RZeitIJHEIzYNV5vX+IvlU+elgVPzLQr7HHpHUC3dpcExd4MqM+f 9VN4cxPJp9fGnZ7vxhfYlgwKh6ElEzpKD5QQ6PXDe X-Gm-Gg: ASbGncu0uOcjPfqoRPvaPgqESjCVqmYmuBtMkKJEqzT85YmeMwKs+AYRqxoKNdazUpX 7p5359RZPq7/Bvqk0LnzDNNxpUKjIySGg39GwyKLKBZL5oqdiQ6je3GvS0z8Pe4GzTZa3LSUCmI qDasSH4wdwP7Y2uxgOD+Mlmaqpr34objsgXYfiaa3b1ChCTCCzyMf6xqKI41yYg/Q6MNX6pQT5a pP8NRaE X-Google-Smtp-Source: AGHT+IGxMFzfxoMshf8o4a14Ejv5ySZeVudjy8uWADR3jrlyocSlHqGDCSnPrW5fBZgeWyiqUxNYjC030ER26Bgve7s= X-Received: by 2002:a17:902:d54f:b0:231:d0ef:e8fb with SMTP id d9443c01a7336-231ffd0e311mr5549935ad.10.1747691660258; Mon, 19 May 2025 14:54:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jann Horn Date: Mon, 19 May 2025 23:53:43 +0200 X-Gm-Features: AX0GCFvlTHWGpQXPrZqZ0zsT-FBytrKftqSVY8o-HTsRuDoHswTfw7vQf9EDQFQ Message-ID: Subject: Re: [RFC PATCH 0/5] add process_madvise() flags to modify behaviour To: Lorenzo Stoakes Cc: Andrew Morton , "Liam R . Howlett" , David Hildenbrand , Vlastimil Babka , Arnd Bergmann , Christian Brauner , linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, SeongJae Park , Usama Arif Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B6233C0007 X-Stat-Signature: na51kfek96tffoxc7jicrpegj9ink5je X-HE-Tag: 1747691661-426390 X-HE-Meta: U2FsdGVkX19cpB2EtGe/oFjLbVpWnutItSR6k+xekQdYycLFXvoMqd5d6PL5T+4ccz3+GqXcUtgTvHDdnULdppSrb/2EWHwW+XpDFhb/RtDsB7cz3bHRCXx8sxf/Lae+20jWEg2fibekjpgXpHwepoc7n4O1BdsVTzDHj8LEXqVpp+8T6DgfyRiueKkFwgxHvLs42eVmdv4H7nkNGy45EThBTBnCuLQUFRvBM1nvZlB87zlHAhYoRk/tl2wMgm2t2TR5ZBq83r0xqr/tVwL2C7xSImm0uz8MJG35c184iin0pN+JQKEsE+4djk1T8nZ9f72YrV8UmVso0jCCOb10wo9YMtkPVxAFnQBUMIR5klQznvSY312RNZdQJ8hkGas4BxPBqvX/ZhVLtolCf1Swy2HEGwOu9ecWAkJ4hn5fy/8shcsxAFu94i96bc+upCi0hX1s3miPws9Vq5XWvGGM7uDSwHgR73X0bUOgkk+350w1xF8PVMGSRgC3011R5SOfCsqks77y48jk6FTllFcI5CrsRac+WHYJ1xelEchBO6sPYkrrAbydY2i1oJIbqLCQqOTFT57T/xEOu+8hLy+ys7US1gPxPY/bxT3+D0lX/m7sfOFfnwhustftd16fJ5cV436owiAkB71yN6lOPG9/SOzlHOsUWV2xEOhHvmWykSjVOI1LCnNPRz88Muh7Fzd2ml3NHm47Dc3KoNgWLN9/OZwGwFRlY5fufWvnccIRT7ue+tXk+IL1bSkSJIKX0OQnuoeTM7ulu6KddmWT0BGB9TcNWkfVSyYvnbG3bswwkt+us9B6jxftSJeuJyf3C0f/tHNfUqs6OMm/YAyI97Flnw4+Io3f59txqKd4y6ZD4mPTcnEw/JjEsuyYiI0MTPgcWsu0ulE3lvf9kv+cd4NmVxzsFJifHZA/XNrmlPxEZm0wACazhdQlcQFEiVmzRBWg6Nvz6cNUE/VMUL+Byh3 GqeomxU2 FXBfi+r7+2SNsRKlPuQDci1WrKT5Ch6rm1oaYj42u/1Nsz2zvwkj2HH7ezCkno6wv5ivfvGKfpt/ZnPentGiO+PjWsbZvOIfy0H4Sj6lVEsZab0q2JdSlo1qbm4KBU7RS5R6NQ2FE4kjlx638OD4y8krEJXzJSTr3AYMuqsLm0BLR/GTVXY0xAyg4ELgV7dUW3wjJo3MsfUy65y/ETpM87ha4l66MTh7yjJKSDMpjdd9yYt26CBdubr4CvvN+qryUhBmK6qnXALjLR/A= 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: List-Subscribe: List-Unsubscribe: On Mon, May 19, 2025 at 10:53=E2=80=AFPM Lorenzo Stoakes wrote: > 3. PMADV_SET_FORK_EXEC_DEFAULT > > It may be desirable for a user to specify that all VMAs mapped in a proce= ss > address space default to having an madvise() behaviour established by > default, in such a fashion as that this persists across fork/exec. Settings that persist across exec are generally a bit dodgy and you have to ask questions like "what happens on setuid execution, could this somehow influence the behavior of a setuid binary in a security-relevant way", and I'm not sure whether that is the case with hugepage flags but I guess it could maybe influence the alignment with which mappings are created or something like that? And if you add more flags to this list later, you'll again have to think about annoying setuid considerations each time. For comparison, personality flags are explicitly supposed to persist across execve, but they can be dangerous (stuff like READ_IMPLIES_EXEC and ADDR_NO_RANDOMIZE), so we have PER_CLEAR_ON_SETID which gets cleared only if the execution is privileged. (Annoyingly, the PER_CLEAR_ON_SETID handling is currently implemented separately for each type of privileged execution we can have [setuid/setgid/fscaps/selinux transition/apparmor transition/smack transition], but I guess you could probably gate it on bprm->secureexec instead...). It would be nice if you could either make this a property of the mm_struct that does not persist across exec, or if that would break your intended usecase, alternatively wipe it on privileged execution. > Since this is a very powerful option that would make no sense for many > advice modes, we explicitly only permit known-safe flags here (currently > MADV_HUGEPAGE and MADV_NOHUGEPAGE only). Ah, sort of like a more generic version of prctl(PR_SET_THP_DISABLE, flag, 0, 0, 0) that also allows opt-in on top of opt-out.