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 9C95AC3ABDD for ; Tue, 20 May 2025 16:05:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36E996B009B; Tue, 20 May 2025 12:05:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 31F4D6B009C; Tue, 20 May 2025 12:05:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 20E4E6B009E; Tue, 20 May 2025 12:05:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 007706B009B for ; Tue, 20 May 2025 12:05:28 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 5E4961608A8 for ; Tue, 20 May 2025 16:05:28 +0000 (UTC) X-FDA: 83463761136.03.54EF96E Received: from mail-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) by imf24.hostedemail.com (Postfix) with ESMTP id 3F590180005 for ; Tue, 20 May 2025 16:05:25 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zkiH8I88; spf=pass (imf24.hostedemail.com: domain of jannh@google.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747757126; a=rsa-sha256; cv=none; b=ln12puYQG/UYLB2HTZ0FSCMoD8CN8RyHHx0l/1sGRFvT8FvLAia9eCvn6Lwq84bH55A8aI j0hTCRwgT9jzFxtaGdUTCWmK5xYnDxuDNDB3pXRk/YvksLGpCLu/1i78QsdjRa94QZg/Et ldzBweki4Jt10HgzpGjGpigkU26/aoE= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=zkiH8I88; spf=pass (imf24.hostedemail.com: domain of jannh@google.com designates 209.85.208.51 as permitted sender) smtp.mailfrom=jannh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747757126; 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=0rfntWFazho4mK9F9eshENfRLYtOEx0ULfCoFJCPcTU=; b=Hqc8NaFbd9//4m3o8fD62mtoEnyxpFWqj21uLsmHtoK1s+A3Py4rKSH/ZTLOblz/xTEkH4 FSsDHDJLZ5QmamVZHlb1BukHQgirLQ0PB8kyj667gtQh0rbd5AblDocwukyrOB55Co9pQF Jn8C2oJkx5AOFZNgwof3Wj8/OxZIzag= Received: by mail-ed1-f51.google.com with SMTP id 4fb4d7f45d1cf-5f438523d6fso23111a12.1 for ; Tue, 20 May 2025 09:05:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1747757125; x=1748361925; 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=0rfntWFazho4mK9F9eshENfRLYtOEx0ULfCoFJCPcTU=; b=zkiH8I88g5NgpZxKpG5samtubnYxvyyKIMxJcaeAw3gJCMOucjokvNog7vxuoB3++L 9ZpDYCTTRdGQJKCEaUyzLPdROccZH7XjhGeZny/muH8Y9xru3X/8Yi8c5MDyreLsdmdC yopLRXCSN9HHljnHZM3hlrlKK3AR/j7EEpOfO2QDQOyJpSIpanVHGSeavYRz06xwLN4P 3PjWnbXmF9psRNOtQP2s09gnq5H0mgq0aONDb+wNrpSxvwYteQzFFJXeEQeITvSoWhjd Q3MKVZpqVSKdE33eXvdFU8dBeHpoi0F/VrmQrP0fW+Y9k13U2V5HqMC/kWXd+kL/dvQ7 liLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1747757125; x=1748361925; 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=0rfntWFazho4mK9F9eshENfRLYtOEx0ULfCoFJCPcTU=; b=jwVcBIcCWBtrml+kEueNEERsTkviJWekwrH18RN5AoBJAeZM78K+E8yDB1NjuPsJwQ 4HQLFaK0cMAbawwAwdQLsNyHZJJdxOkAbot+5/o1X28/5MSMGqA+AEPkG+nO+Fn8ocxO t3M4dPmq8L57cJTKIiPKYX/+8uNRYLKKcaaPxFmT2rTpBXKMQ4jjF+fPjHlWqKykmIjm cDHP75Zv0JVdaRfS5icBsQoYoyzDrmfF0tDb6BhsOrLguVKkIMBhWrc7G1I8/Tvnynjr BWODLzJSfL4Cm8q+xZF+lPQi/rNsbhKJRgPYmexzOmKawr4Vglrv0/o5DmjNYb8eSL0U //7g== X-Forwarded-Encrypted: i=1; AJvYcCWbPYjTHHjPcREYpjJQXpBuaezcDYmQk6jdaDJtiGLOCfYYnm53Q6K/9bVzK/Mx1yrZnKk4icgClA==@kvack.org X-Gm-Message-State: AOJu0YzQriu99cA/YgBf78OtlYVtRCVrp5BVWVrKrDWgIK13rcDMfZuS ioagfZiJY91sdcV9q4GJI17y1EIeb7OT5EeMVUtxXpd148CNFHiyPfQUxNE4Vq2YxHdJUtDv3Jh aR5xY0JQyeTpAP4d9Fnv+yVLyeALthHDfzhze7QTP X-Gm-Gg: ASbGncs4KVijkXUn6Qjga5xAfURzHITkvTfHhWiVvBKjHCG75+ShbCCl9xGZfQPc1eC dl6liDUct+VAlse51vAZH6z8doRlCvUKDog7Q9qa1i7H19cRGsBUhrXxwiru8N3FbgtKFRWJldv uew2NeZ1+vSlAcVrOh3NuF/SwPm41QV+puwcuwqNhjiPLLFKnrWRfh+dUay3ZdVdh2+iBaiQ== X-Google-Smtp-Source: AGHT+IEOQ2vFE3jecYWUn3oKnGtTWjIT++RWO5aGS6gOAXZFLqR0bXLZnvv/yrhnUofHKsIUGByrvi7YUdoaE5rGLCU= X-Received: by 2002:aa7:dd08:0:b0:600:9008:4a40 with SMTP id 4fb4d7f45d1cf-6019c88648dmr301495a12.4.1747757124254; Tue, 20 May 2025 09:05:24 -0700 (PDT) MIME-Version: 1.0 References: <368b0ca0-605e-4d2b-b12e-c24b1734d1c2@lucifer.local> In-Reply-To: <368b0ca0-605e-4d2b-b12e-c24b1734d1c2@lucifer.local> From: Jann Horn Date: Tue, 20 May 2025 18:04:47 +0200 X-Gm-Features: AX0GCFsPdY0pLyAGHK-EG0PUc1QDFfH1ipfBEhtjta5dZf6rJFGtFMXyimrWtdo 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: rspam01 X-Rspamd-Queue-Id: 3F590180005 X-Stat-Signature: 75imbn39xqsc4o7b1roxgozeu3iaph8d X-HE-Tag: 1747757125-383579 X-HE-Meta: U2FsdGVkX1/2b0Njcct/fOG1buAsLkI8WGX7tGWpiWC36P2OVTts6zWdcAE4LdA4xAiYVlKPx7ENW2jubcvcDXeqbfTWdeLvqz3rH0Il37OzjUpw46U7LSJayXtIbK1eHJms1QO2A2A7DHAuFzu7wKBG5PCQjp82tg/IXeBy0O9xdog018xmyGOy4bn8y/szE2MHJAFEMlp72Kaj8bNomu6RhVFf89Ywuu76M3QACHgscjyuUmD9RCQgLwzQVCKRgIy0Kn/Mzr+SVWESGHtv6qBuV+S1XOm3PLDi59kTeQA1NNvKV/jazwv/JPwMKpYlqtMRiBVo6sEwdAZhm4UXFOXUtjdXzLfNMxfejCLcpd0PIHtxZNaR7TnUivl3GgJvnfhLuS98luhtEGPlZ7VTALUeS1FLnRNi9iTTYVbFXQ+WfoVfSThdKI3+iG/z5cHzlKWJ+CxBKC6cuCYyYUfB+83TUA1adaSRgSkuTykFi5yrLMFPThJxdLKkPpkCiedkXrZNCNqtHp8sD3nhVRvnjIIHsYst+bRJkQ9S7rkmpS5FEhm3EMPAjbgd6qCLcOORdqnEdFBtoOZOltEq+b9aDp/di9kExjlKumJdeukfaMK93R43bZ0XPAVx2KFiBR66PJtCeYYjwecIIkSVchmqS+8wdWM7olM3LNv8BG3j3ZFxra9xrjs3ELXCWBHnl4+CNBqF1o7uCejcwtZ5tIP60LUFBR/C8xjYw45cI247NXqh4YPjafAKClDFaCfxTKWcyx3AjQX4/e1y/VOzTzdrrhO8HrJTumSkuxhz2aJ4YOw1/x+jXvVp6yQ0vYO74+PMrUqSRSu6gtcTa10SNLJQbf2qQtVhk9Cpv4ZCm0GoXeSbQczFEkV/rzoxKhu3wUPAYR/MjQyyKCI1Kvo/r+dikReRZsZ3grkXwxAkbHM5555HJNubn03o+PDsSAtq2R4Vm44GALFnAxoGjDzUb0n KQcnUXOy 82h96eQDHcCNonmChFD9VnUfAlfX4g7c2STL0Sryk8iyWjYOWn2jNd4x2SLhWxC/TawnYPyUeZ5of+hWLRPVX+Fz9MqvcOagAEZDj75T1hOLSDBqRjifZxb8axmr2CEN78xbqu8PTIr5av+mDL9zaDRLIn43Q2RX2BGKbJiik3ZWTz/YXwmbDZjq2Z4r/4W0w1AcNP6btBaysRdUOoqfIvTGISNrx5Djt1+oo2GR3CEVATEKj2e0hp7hcsBnqhs/DWRctbndztuoBTQw= 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 Tue, May 20, 2025 at 7:36=E2=80=AFAM Lorenzo Stoakes wrote: > On Mon, May 19, 2025 at 11:53:43PM +0200, Jann Horn wrote: > > 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. > > The use case specifically requires persistence, unfortunately (we are sti= ll > determining whether this makes sense however - it is by no means a 'done > deal' that we're accepting this as a thing). > > I suppose wiping on privileged execution could be achieved by storing a > mask of these permitted flags and clearing that mask in mm->def_flags at > this point? Oh, I see, we're already inheriting VM_NOHUGEPAGE on execve through mm->def_flags, with the bitmask VM_INIT_DEF_MASK controlling what is inheritable? Hmmmm... I guess turning hugepages _off_ should be fine... Yeah I guess I'd do this by adding another bitmask VM_INIT_DEF_MASK_SECUREEXEC or something like that, and then applying that bitmask on setuid execution.