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 28923C021B8 for ; Wed, 26 Feb 2025 07:35:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9BEC76B007B; Wed, 26 Feb 2025 02:35:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 94753280002; Wed, 26 Feb 2025 02:35:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7C1576B0085; Wed, 26 Feb 2025 02:35:11 -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 5A3EC6B007B for ; Wed, 26 Feb 2025 02:35:11 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 09F931C8ADE for ; Wed, 26 Feb 2025 07:35:11 +0000 (UTC) X-FDA: 83161284822.16.BDC053D Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf20.hostedemail.com (Postfix) with ESMTP id 2458B1C0012 for ; Wed, 26 Feb 2025 07:35:08 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="qZpme/w+"; dkim=pass header.d=linutronix.de header.s=2020e header.b=GG5eJRbw; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf20.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740555309; a=rsa-sha256; cv=none; b=R2yiMNntyTBg1pvdF5F+MLolLSiaAwtVBR0sE31/JXJs9Q3mbh7FDjUBvbCJzpJxYvHoox ogEpQI5CJt6OsJpqT1wRywZjauSRuCl0celZnyhhn/ETZL1XBV+NkaMk7KtkwDrArtwIAl s+SqKmHKD4fZJJIDMeqzR6rYSYGnUfI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740555309; 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=scHHpoERaISGWPCPSfxNtAEwSLspOWsXVfCnJqqdlO0=; b=gYgDPgq+IcMga/f0XsPQ9CSwTyEnQYX7Cq9WjUUQ0yk56uJddjtbeBxfGxp5R/RLzwDlfN 10HSn9oW4081jmPmb5zajvLoslh11wHIxdoKF2gfCcUeD0febtrzRn0CjELEylLGzL23Nm W5WjnrrQ2Gd9G9fg2XHWmdF0hjMG8II= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b="qZpme/w+"; dkim=pass header.d=linutronix.de header.s=2020e header.b=GG5eJRbw; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf20.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de Date: Wed, 26 Feb 2025 08:35:05 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1740555307; h=from:from: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; bh=scHHpoERaISGWPCPSfxNtAEwSLspOWsXVfCnJqqdlO0=; b=qZpme/w+VIp8r455uKbsVXT4drb1iNMy5qXAcQFs566PspJzxeb2LW204xs8gTekXPRYiw dPtVIaYre4dX3YpqyIrhcC6cJjV1FGZCwodgj1YV7F/a5f96xeRwhyPa8mmeC8lyNNZrdq 1lZ82Lxmgma94Z/boUSYX1V04+PplNLe58UJ3PreQEae9Bi58DNY13+7e06xrOjVXvyU2K xwrP0tSdbU6E6uQdX/Rs+OCuh/xDwmdwjFeWzGsEjp/AGWGn5b0Jh2//rN3j08iFScYT+w m92Lho6vcSA32o25Cx7cZ69QNKLnCcy3/TC+PMojRWprwHSzQtVgX2TiAm2w1w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1740555307; h=from:from: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; bh=scHHpoERaISGWPCPSfxNtAEwSLspOWsXVfCnJqqdlO0=; b=GG5eJRbw2mKG7jVbCJ3hQcaxb87U5Koj3eTzeWIDDQ0u/Zk9dj2CkkjwGU22Nvgc3WbEwW +pVAJiTdu6pP/DBQ== From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= To: Jeff Xu Cc: akpm@linux-foundation.org, keescook@chromium.org, jannh@google.com, torvalds@linux-foundation.org, vbabka@suse.cz, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, adhemerval.zanella@linaro.org, oleg@redhat.com, avagin@gmail.com, benjamin@sipsolutions.net, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, sroettger@google.com, hch@lst.de, ojeda@kernel.org, adobriyan@gmail.com, johannes@sipsolutions.net, pedro.falcato@gmail.com, hca@linux.ibm.com, willy@infradead.org, anna-maria@linutronix.de, mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net, peterx@redhat.com, f.fainelli@gmail.com, gerg@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org, mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org, ardb@google.com, enh@google.com, rientjes@google.com, groeck@chromium.org, mpe@ellerman.id.au, aleksandr.mikhalitsyn@canonical.com, mike.rapoport@gmail.com Subject: Re: [PATCH v7 3/7] mseal, system mappings: enable x86-64 Message-ID: <20250226082701-9057b348-b074-488f-9aca-49ffbc78237f@linutronix.de> References: <20250224225246.3712295-1-jeffxu@google.com> <20250224225246.3712295-4-jeffxu@google.com> <20250225085728-24167715-8562-45a8-86cd-0ea503e4bc73@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 2458B1C0012 X-Rspamd-Server: rspam08 X-Rspam-User: X-Stat-Signature: zxs7ctwc7kftq6hr9u769wubgp9buz6k X-HE-Tag: 1740555308-301506 X-HE-Meta: U2FsdGVkX1/LDfzOtd/h29khiivzaZz/yrkUscJBtFh3fzcIwqShIyQ6HUf6fVtF4Dxyg/myPzy9yqW/JEnCclw0Uv8RGGbt0iLBux8Lum6yGPRpp7T6zjdbWt8FrP/9de0bSM/ZJSnlM5o3K7R1uTBKUM51zKWjsZ3AyQPCTJTGuxo19wfWeRea8cnpUE8GnJ83xCGPr6q4vzUzpEu6UM/cAkhjByJffTl/gZRXo/FdwOVEjCLUGjxfV8IZlvINmmyDbc4aCNPyP2JQQnYXoWDkrUovVjRAKY6+5YqeGBITA+2YX9JeXizPhLZbtJ0Kl/f/UrbIhAxqtpLl8X1lNMCGC2K3k9hJkznKX64znBEgEg2nvA81K+7CGUmx7Tsf7QdFpXs+AeXZdd+o3K0x7ALOCnqqLFfM7Q6e+u9hD3LCocOV0dk+9FyTGeSA/WSYeK5Ir7k3gWtZGfG6yg8bNDkCU45yB1V/CgvalEfezThNCXJhFUvcVIMl3wu2eXj0vChXakqUrkDnvgL3HZ0EdZtPuaDupfypLFGu+4X2zRljl4T9DQTMMsr400HHKAb0tC+k88pbTt6WqFOzXA59Gl1SxckkXWvac+S0krhrH6A0TG7o6I/h0qjiI3niqcp1fKChM2X+l8dL0W89ItG5Ov62+V3Q5hqYR1wmOeBiVyt8RIR/DH09QRPnZ15bdBfuPkO++FNIiZFaIBG7vo3DdcRHRDoXIOY+XERAEB9/PL53EK9cEjJox7/P1Dc337rbajiGTlDD0bFXYo+jTmX2/KgiAzNTLyzELFlJGeWMo5xAiHs3zPwULzEZw71kunGI6IyvdbFhtCmzRNy9mRpx+2HTncjQeDzD/DqtDR2i3AxWy/NoxHhBA9VySKsp7nhSA5gquIKWdb6InS91EGb1skjZ6LwTmlDjrM26ARlflfHb8VHdBIi9rScKGgJ7XRCnwtVzX+4jUwadxJHvvtK lap0ieg2 Pqza2Jm0ApuypjU97EzFrQUMrISsbOpGRYsTQCQv0LTK8GBtWku/qVkNpKOMUdeNZUFk7KaQeOIzfp1V0HWlyGCs91TPOmzocCeJVUPCjA4tD8vyzqS3vHdbdej6xG1uIVPIbbAaw7rZwpHz/T04YRAhHP2sKZmU8WViz5ECr314Vr+T2zTpGzPxYk6vUDzC4w+NLWJ8lLqEv1RyXicy38IGikFKW6/rKcXUlRZzzO1SorHP4x9f8T7wXb/TvXtQvKuN4KVZPwcRc/jrwUal74e1L5B0Z/apLSrb/HNqQhaTg+5d0pzSXJU7qCJJrTcHJ1d7Gps8EsR/MOzcEa88CbYZbCMdeyqe9wG4LUVfFlRkx23mqbjhZZR3REhuPpIaiTitkU8KP0DV4xDVE83IdYQDpisAO4b61rDhH6zQ3t5KBLFuoEuU2Znzauqs6i2U7LGLP23At8Bm0nuoCaeXnt8/AJJxVxj7FPegBn14oyaiRYdnHr0uYZ9U5YfnlAmUbOmePmxlpFr5+ICe5bTbX488nULZno1fVdULLaZSLpO8qZKw= 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, Feb 25, 2025 at 04:48:47PM -0800, Jeff Xu wrote: > On Tue, Feb 25, 2025 at 12:08 AM Thomas Weißschuh > wrote: > > On Mon, Feb 24, 2025 at 10:52:42PM +0000, jeffxu@chromium.org wrote: > > > From: Jeff Xu > > > > > > Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on x86-64, > > > covering the vdso, vvar, vvar_vclock. > > > > > > Production release testing passes on Android and Chrome OS. > > > > > > Signed-off-by: Jeff Xu > > > --- > > > arch/x86/Kconfig | 1 + > > > arch/x86/entry/vdso/vma.c | 16 ++++++++++------ > > > 2 files changed, 11 insertions(+), 6 deletions(-) > > > > > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > > > index 87198d957e2f..8fa17032ca46 100644 > > > --- a/arch/x86/Kconfig > > > +++ b/arch/x86/Kconfig > > > @@ -26,6 +26,7 @@ config X86_64 > > > depends on 64BIT > > > # Options that are inherently 64-bit kernel only: > > > select ARCH_HAS_GIGANTIC_PAGE > > > + select ARCH_HAS_MSEAL_SYSTEM_MAPPINGS > > > select ARCH_SUPPORTS_INT128 if CC_HAS_INT128 > > > select ARCH_SUPPORTS_PER_VMA_LOCK > > > select ARCH_SUPPORTS_HUGE_PFNMAP if TRANSPARENT_HUGEPAGE > > > diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c > > > index 39e6efc1a9ca..1b1c009f20a8 100644 > > > --- a/arch/x86/entry/vdso/vma.c > > > +++ b/arch/x86/entry/vdso/vma.c > > > @@ -247,6 +247,7 @@ static int map_vdso(const struct vdso_image *image, unsigned long addr) > > > struct mm_struct *mm = current->mm; > > > struct vm_area_struct *vma; > > > unsigned long text_start; > > > + unsigned long vm_flags; > > > int ret = 0; > > > > > > if (mmap_write_lock_killable(mm)) > > > @@ -264,11 +265,12 @@ static int map_vdso(const struct vdso_image *image, unsigned long addr) > > > /* > > > * MAYWRITE to allow gdb to COW and set breakpoints > > > */ > > > + vm_flags = VM_READ|VM_EXEC|VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC; > > > + vm_flags |= VM_SEALED_SYSMAP; > > > vma = _install_special_mapping(mm, > > > text_start, > > > image->size, > > > - VM_READ|VM_EXEC| > > > - VM_MAYREAD|VM_MAYWRITE|VM_MAYEXEC, > > > + vm_flags, > > > &vdso_mapping); > > > > > > if (IS_ERR(vma)) { > > > @@ -276,11 +278,12 @@ static int map_vdso(const struct vdso_image *image, unsigned long addr) > > > goto up_fail; > > > } > > > > > > + vm_flags = VM_READ|VM_MAYREAD|VM_IO|VM_DONTDUMP|VM_PFNMAP; > > > + vm_flags |= VM_SEALED_SYSMAP; > > > vma = _install_special_mapping(mm, > > > addr, > > > (__VVAR_PAGES - VDSO_NR_VCLOCK_PAGES) * PAGE_SIZE, > > > - VM_READ|VM_MAYREAD|VM_IO|VM_DONTDUMP| > > > - VM_PFNMAP, > > > + vm_flags, > > > &vvar_mapping); > > > > This hunk (and the vvar mapping in the arm64 patch) will conflict with my > > "Generic vDSO datapage" series. > > That series is already part of the tip tree (branch timers/vdso) and scheduled > > for the next merge window. > > > > https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/log/?h=timers/vdso > > > > The conflict resolution is fairly easy: > > Move the new flag logic into lib/vdso/datastore.c > > > Thank you for bringing this to my attention. > > In your change, it seems lib/vdso/datastore.c implements a > vdso_install_vvar_mapping(), then all the architectures call this > function. Correct. At least all the architectures using the generic vDSO infrastructure, which are the ones you care about. Sparc for example has its own implementation. > So merging conflict won't be as straightforward. Wouldn't it be enough to unconditionally use VM_SEALED_SYSMAP in vdso_install_vvar_mapping()? The symbol is a noop on architectures or configurations where the new functionality is not available or enabled. > Maybe a better > approach is that I continue resolving all the comments, based on the > latest main. Then wait for your change to be merged and submit another > version. That would work, too. As you prefer.