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 688BAC5B552 for ; Tue, 10 Jun 2025 15:03:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DD7CD6B007B; Tue, 10 Jun 2025 11:03:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DAFE76B0089; Tue, 10 Jun 2025 11:03:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9DD66B008C; Tue, 10 Jun 2025 11:03:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A8B036B007B for ; Tue, 10 Jun 2025 11:03:13 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4C7FE1A0633 for ; Tue, 10 Jun 2025 15:03:13 +0000 (UTC) X-FDA: 83539809066.20.A94D06F Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf08.hostedemail.com (Postfix) with ESMTP id 2FC87160028 for ; Tue, 10 Jun 2025 15:03:10 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DCyQID3p; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749567791; a=rsa-sha256; cv=none; b=GBsRZVsVmGgF3YcVo+y9iR6Bi0tH5KsfVOOWJlrbLjowPrwcWouVukLs/kf2PWigzJ4d5+ BtzlJcgoiu64Y4t/VbBEMx7XcWVybeI28YtdARMRNIlg6kSGidI3gCekmCPbLKlFT9ZfuR 88SybtKZ160Z1cTAuU5fYiKsNpeXNFY= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DCyQID3p; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf08.hostedemail.com: domain of usamaarif642@gmail.com designates 209.85.208.41 as permitted sender) smtp.mailfrom=usamaarif642@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749567791; 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=CDC9yplPkoPW2UltO3ycsW0uGRdrvTKeooKsDUH271I=; b=kGDtldZXG6jN0bHTQJ2Zmv9hasDNEGaNWEGB5L1ZNjDzPt3iP4wXVvgiBYGaJhtjt4bk8G 9kcK+0Utix3fz0lXDekEKNHj+oIENJvXQ+OsXLdLoWabOvTtrGhQjYsSlrM270tE3INeFV NJ1A8AI6S2Sk3aJDLfGNOOQxyoL4q8M= Received: by mail-ed1-f41.google.com with SMTP id 4fb4d7f45d1cf-607ec30df2bso4640812a12.1 for ; Tue, 10 Jun 2025 08:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1749567789; x=1750172589; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=CDC9yplPkoPW2UltO3ycsW0uGRdrvTKeooKsDUH271I=; b=DCyQID3pP/waIU+JK1mYSpACEyqjw/21rIXN/MFiXAa+naG2TpOLsVN+JmkeL4tOeg 4hDAN4G4aswR/2hbjXFBvlB+qUrLjR0SAQGn45J1PhamqXfDGIdS6AsBHPBzfrVDnFaf +RE6N6TVvM5jycj/ikcpvQKyva1Qzeg+EgvktoD0X9LgbKljLUnSN25XHRVbvyk+MrAx JVSqsGS/PzAtg4WEFvUfQX1sfXc500Si9tVdaxRlcPL9mf8IMONvKEzOm4IzSz16M8VG unMNCHYsH308dZxdzPSJYpGjJpk+qG2MKLtt5fHOhnHvBxoxTplJuanntUleGUmgX2xV tH7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749567789; x=1750172589; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CDC9yplPkoPW2UltO3ycsW0uGRdrvTKeooKsDUH271I=; b=duWVapsFzZ/JKEV84fc9S5zHDfo/03GJgfbvxqeEMsQS1ir+G+JCqa4vFnlns3Ulf0 3dVsObSztk01dir7S1Y6qeOqBvAZ97jP+aR+T1Mu1rzIUabMVun+eqNM04VAb2pFaVa7 fv9uUh9petpxR9XVoUXjjaDJsVyBWFxxyzZ2Q7mDM2f8pZtYIimpr5a0wA3Q3dnwsozI urIV3sDLOjDWFY09nVe88ljGB7Qxo6LdpsLuenemTh2zMxxhsCi/O5GzPJ7/nxeHW+6V jOb9FKijYioNyRJRL2ZJlTDBD6iD4INiYInvL/EZDHQ6ZTSyAk7ZRstpHwzZiKRw2txU j6rw== X-Forwarded-Encrypted: i=1; AJvYcCXofxlYdtxGEBheWTWAkUpeKjgrVjqr/4s1FAKVob8k0QWblHyyIlCoRu+aOi5XuC2tAE9PpcyHsQ==@kvack.org X-Gm-Message-State: AOJu0YyW/XGMjdEoGWqe1TcR31nsSktYFPAINwVthHN0SkFY1jhN2l7p CF8B9NEHLHhpfAjVXxQPuBBdzNeUSf9LPaELJtSAl2z6uYGkrM/KPE0l X-Gm-Gg: ASbGncv1+xwv7p17DjuyQiuTzJDfOgNl66eoln34sV9floL+Yl2uPjbnkegeF9iNOkL 2zUykk15S3fc0ujglXrqkVfDiXLO2rcGXN4nkVI0hdN+KxbsH5lwSJS5FsKjWmLJzaNOn+srQ+C 6FVx8vBAtf6VUXQvxqpUnOGQ4dZWt3IZKC1dMpU+YNVeRhVAg2jptVRMGg4C5cHN2zyM8mRJP++ 7SS0WbgHwOrPbVyavyfKXYxG143l0Lb+iGcUOtq7DrYG33fXDBoi0osvaE3WRcIy1InE7QVK/AV QJa23NL4rEE6Q+gwcNMRfBxCC04R/V4tRFSJc79+pL2xT0eSE4p7amz27J38L9dIsG0V0vGV1w/ Z7NhGBPKwA0n+JULeIcVMqsfq6QFhH/Cd X-Google-Smtp-Source: AGHT+IExlHW6J/JO614E8U398K85uzXlylL1u+bp5hpmTla2vYCO+oDTvmf4xA+H2Z2h6vgzqSc3pg== X-Received: by 2002:a17:907:720c:b0:ad5:749b:a735 with SMTP id a640c23a62f3a-ade7ac7bd0amr294841766b.27.1749567789056; Tue, 10 Jun 2025 08:03:09 -0700 (PDT) Received: from ?IPV6:2a03:83e0:1126:4:c2f:a34:6718:ee1d? ([2620:10d:c092:500::7:b9b7]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ade1d754669sm733541266b.33.2025.06.10.08.03.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Jun 2025 08:03:08 -0700 (PDT) Message-ID: Date: Tue, 10 Jun 2025 16:03:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [DISCUSSION] proposed mctl() API To: Lorenzo Stoakes Cc: Andrew Morton , Shakeel Butt , "Liam R . Howlett" , David Hildenbrand , Vlastimil Babka , Jann Horn , Arnd Bergmann , Christian Brauner , SeongJae Park , Mike Rapoport , Johannes Weiner , Barry Song <21cnbao@gmail.com>, linux-mm@kvack.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Pedro Falcato References: <85778a76-7dc8-4ea8-8827-acb45f74ee05@lucifer.local> Content-Language: en-US From: Usama Arif In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam01 X-Stat-Signature: sg1axcmy1xugi5eerdn777wyrknogtcg X-Rspamd-Queue-Id: 2FC87160028 X-Rspam-User: X-HE-Tag: 1749567790-384856 X-HE-Meta: U2FsdGVkX1/pto/5EaI7oRWfYR5NH8PYXfMi3/tw9zBTHo/OixkIxAinudyJ/C33Csif+3MR6N1hTWGXQfE0aimE+62TQ9HnHxXKU6Mdj7YCh4tirnWJ9/Ps+VVn/uq/kqY5jgkiB1JcALHMR6J27WfwT5IkTU3J6lrNLbufs8StH9YyBOOdoUuLgT0OPnI6nxSpWzt6SAKK8nKJGXvSA5rjIgQMwv9Dgqxu1MwPRkQcJG5fvaZ2nSZB3LWxdWcCLfovkjzQzrMqCP45J/2b3uWfGoS+JFFU8xPrTnNp2oscHD5xquUBhqdmyw+G564lE+jp7MCDtjeGhnMxsj5kZ6nnlGuN7EGPTh8PbCIdUW2ZjqrVSEaScRyOTrZA68tPQanNmaxDx0UqpEIBWhL4MUA+8PMdA//rU6dQOHgVNepLhxXx85//0qtxbdkVJvN3Ea1n1nSEfOG3tlTvJVAIHULzyWq6TNO3PSVLm0LM+fFMDqmwtOGN+kWwreeoSd47fep9kuDWXh5R9cE6zj1l2x8XnRTrncxicrAqf2BFm9nb9yOKMWaWvntQTVmNUvp1dEI0KfNlAjYCOTQGdv3cob0DyY2+wjsXo/mfSP5Aa2bJeXIsDoimWnqQJlmF5s6MhEhDMKOSoG/Z8n429k8cXu+3uhyTm7OwIhn8+DeaHgsKM0xVsN0sXQwhQcxrELtTIXmObIjyG8fwzTnLOJP/acJ1l8dSChxlRLkpnRswaAHiMkGegWAkvYecO0NrS51I2PYF0inHrzP3hepwdWNPZVf6/Buk9j3tNYVN7QBSDQUOiElN5Kpk9nbULgrLbfI9hV1bra+L1/SJS9Bs81wUsKR9C+a0nPUR3s6GYv3DekTzeosjdqtDCR4Ndfd5x0jUTF78rVQFb8XDVOSs+lWlUbuXy882VxVKWHf6iEmzQGcohF7sf7GXM+r2PLFCebTiGADr1zEqY700MNcaIl+ wcPFyH37 53bYqS9CUdTTVxhpJ8mrIp8INzgM6vE239oxc5JnKcMgfBONHGweE6T3T/CKDIJYPsn2tMEUS/GHvKjvYHXzLJsv/7kZeES7D4crB5A33EnGqNCJ84oWhzm6zqwl0g9BoAxSxbCaYgvWj0IDhsW30QxkHAiIhV+CFOOaIYeRJY+ven+zhctvfHCN8fiIyQ2RO5osF1LDVog0eJyKAnbsYxJuOxBYTEJ/lEL3sHqJXBXMSijYi2/hOlTCFMPLQ5h1qm60qeIoHWcng4lk6fIeToXifZeXzGZKXhzphFwXT8bl8NlV9mNH3gL38omwZDcYC++MEBE5X9LHkFiRVecZHSlGMq8oHTOKQlkaYNXhdipm1P9bhaaA5G+36NDXon+Mp6PXM1vD9/jecL8/CmP9+d3cToNiw0aRUtvH2dTmEdSeghfIe2ZPmUZPAs1TH4I6vdMdlRVHWnh5T6+tjDgxCeG5EcA== 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 30/05/2025 14:10, Lorenzo Stoakes wrote: > On Thu, May 29, 2025 at 06:21:55PM +0100, Usama Arif wrote: >> >> >> My knowledge is security is limited, so please bare with me, but I actually >> didn't understand the security issue and the need for CAP_SYS_ADMIN for >> doing VM_(NO)HUGEPAGE. >> >> A process can already madvise its own VMAs, and this is just doing that >> for the entire process. And VM_INIT_DEF_MASK is already set to VM_NOHUGEPAGE >> so it will be inherited by the parent. Just adding VM_HUGEPAGE shouldnt be >> a issue? Inheriting MMF_VM_HUGEPAGE will mean that khugepaged would enter >> for that process as well, which again doesnt seem like a security issue >> to me. > > W.R.T. the current process, the Issue is one Jann raised, in relation to > propagation of behaviour to privileged (e.g. setuid) processes. > But what is the actual security issue of having hugepages (or not having them) when the process is running with setuid? I know the cgroup proposal has been shot down, but lets imagine if this was a cgroup setting, similar to the other memory controls we have, for e.g. memory.swap.{max,high,peak}. We can chown the cgroup so that the property is set by unprivileged process. Having the process swap with setuid when the unprivileged process has swap disabled in the cgroup is not the right behaviour. What currently happens is that the process after obtaining the higher privilege level doesn't swap as well. Similarly for hugepages, if it was a cgroup level setting, having the process give hugepages always with setuid when the unprivileged user had it disabled it or vice versa would not be the right behaviour. Another example is PR_SET_MEMORY_MERGE, setuid does not change how it works as far as I can tell. So madlibs I dont see what the security issue is and why we would need to elevate privileges to do this. > W.R.T. remote processes, obviously we want to make sure we are permitted to do > so. > I know that this needs to be future proof. But I don't actually know of a real world usecase where we want to do any of these things for remote processes. Whether its the existing per process changes like PR_SET_MEMORY_MERGE for KSM and PR_SET_THP_DISABLE for THP or the newer proposals of PR_DEFAULT_MADV_(NO)HUGEPAGE or Barrys proposal. All of them are for the process itself (and its children by fork+exec) and not for remote processes. As we try to make our changes usecase driven, I think we should not add support for remote processes (which is another reason why I think this might sit better in prctl).