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 3E814C02194 for ; Thu, 6 Feb 2025 13:24:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A6F9B6B0082; Thu, 6 Feb 2025 08:24:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9F7EA6B0083; Thu, 6 Feb 2025 08:24:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 871B26B0085; Thu, 6 Feb 2025 08:24:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 680266B0082 for ; Thu, 6 Feb 2025 08:24:38 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D8999813DE for ; Thu, 6 Feb 2025 13:20:27 +0000 (UTC) X-FDA: 83089578936.05.A697888 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf04.hostedemail.com (Postfix) with ESMTP id A8F6A4006B for ; Thu, 6 Feb 2025 13:20:25 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=Vsra+7bh; dkim=pass header.d=linutronix.de header.s=2020e header.b="IvIe/z1D"; spf=pass (imf04.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738848026; 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=0Ud3Qu2rXs7gKlmPU8x2diyWcmreX5g6Jir9z7AYo2Q=; b=JeJbfhS9wy0mXlRqu2/wiVoDNS27EAQOajIkfFYbk21sTP8W2eSIBcdAeMR4+BZZvEaK/L FVDHWazbFE1HtaMHwu/BtIlmrTCiecm4IKPHIw0BMkg13gApG1HZc8e8KrW6TDIC2lcPjs BR/tZiLyj5lTkQo6HueMXzr9Pw+GeEI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738848026; a=rsa-sha256; cv=none; b=BfQRIEEGuqwiXn3hDIpyQc5PuYHy7acGQH1gocQRB61Mt2JYTikc86nOsc3as2XjdFQb8z dH4VUoCXc0dwPZ+QMEnUpJW4qhKZcKgwcLfNJwtZNxv/5iYdFU53It6gXQQmuLGIcPAdjJ NdaTqTsdtVdy867UYZwf8S6vEORK75U= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=Vsra+7bh; dkim=pass header.d=linutronix.de header.s=2020e header.b="IvIe/z1D"; spf=pass (imf04.hostedemail.com: domain of t-8ch@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=t-8ch@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de Date: Thu, 6 Feb 2025 14:20:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1738848023; 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=0Ud3Qu2rXs7gKlmPU8x2diyWcmreX5g6Jir9z7AYo2Q=; b=Vsra+7bhKm9lHVvPeMv4HsaPWHQq0miNDYD4giIigcTE6+1b92B9WaqzWrT+Hhbjp9x4hO etvZB5QjHgy0MhYdnIdnRqAOlhb6RGf3UT9ohGnEzoODPuqjNCsCHwm7zRtLEDbNZh0ZxX 1JdnkzAzcUj3XNu/4i+ZL92CL37DzoXS1cVcRiJqSPMngIOAeTtEJ6AhFdKsWf8FZjb8m8 I+4K3HvD6HkGXwNw4AH7pI9OEl5GND7Uhqp/72nm3UTppsPaMyT/B0vuCCqz8MeThBGCdT CnT7lh5XcqFgpH2c0N8vk+zFjAfWsf+KGd3HHQPYylr3cP/OaWCfyFEuA+EEhw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1738848023; 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=0Ud3Qu2rXs7gKlmPU8x2diyWcmreX5g6Jir9z7AYo2Q=; b=IvIe/z1DEyPwDIET7ND0p6Do1/gTd/Eu+o6lDk7vaU30Voa8a/qwsrPUCezHNX9XvfwWDZ ZrVHN26MvqfrHGBA== From: Thomas =?utf-8?Q?Wei=C3=9Fschuh?= To: enh Cc: Jeff Xu , Pedro Falcato , Benjamin Berg , Lorenzo Stoakes , Kees Cook , akpm@linux-foundation.org, jannh@google.com, torvalds@linux-foundation.org, adhemerval.zanella@linaro.org, oleg@redhat.com, linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, linux-mm@kvack.org, jorgelo@chromium.org, sroettger@google.com, ojeda@kernel.org, adobriyan@gmail.com, anna-maria@linutronix.de, mark.rutland@arm.com, linus.walleij@linaro.org, Jason@zx2c4.com, deller@gmx.de, rdunlap@infradead.org, davem@davemloft.net, hch@lst.de, peterx@redhat.com, hca@linux.ibm.com, f.fainelli@gmail.com, gerg@kernel.org, dave.hansen@linux.intel.com, mingo@kernel.org, ardb@kernel.org, Liam.Howlett@oracle.com, mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org, ardb@google.com, rientjes@google.com, groeck@chromium.org, mpe@ellerman.id.au, Vlastimil Babka , Andrei Vagin , Dmitry Safonov <0x7f454c46@gmail.com>, Mike Rapoport , Alexander Mikhalitsyn Subject: Re: [PATCH v4 1/1] exec: seal system mappings Message-ID: <20250206135150-6c770e7d-9af8-4924-b760-82cff5092586@linutronix.de> References: <202501061647.6C8F34CB1A@keescook> <5cf1601b-70c3-45bb-81ef-416d89c415c2@lucifer.local> <7071878c-7857-4acd-ac27-f049cbc84de2@lucifer.local> <2e5de601da34342d8eb0d8319dcf81ff213c7ef0.camel@sipsolutions.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: dx7q9xm89i8xup95ez1mdsc3rrod9m97 X-Rspam-User: X-Rspamd-Queue-Id: A8F6A4006B X-Rspamd-Server: rspam03 X-HE-Tag: 1738848025-508899 X-HE-Meta: U2FsdGVkX18Xo0XKMvIERizYB7t9WaAjn0cRdzlSI0jFmhJZEnFARLAM4pWHyRX+wtQM8i9Qqa5WnLf24W5PD0Y9M03MRcvGUZdb5QTaVNFojWndYVALl8LarWU3FR5SBO85LlqTO9iNg8VuxwsNfCz/vqFdpyuOBxqGfG9/GOPC/5UZxuY/zTdisY0mgijg8yOhrB7X5f/gc7yfMoLPLdFk6gNcsnOQs/xgdlI6TJSpA3ffY5bRq4I/PiZwqyPkWPyQzUk0MeMHsd/LTwO7Fb06zM0gm6cGwFZgE0kadSBux+z6za47Oi3qEGKTNYL694CvKTjmElolFxJMViAZJEHY4ZphdkdgvbdWtumyUZ7EpBGicl6uiEoG2FK1VmfowlyOJ7eH2Vu+8QC95zJiKIHjPrVjK5TJ0P2yV0fIOnqCpSc+4mgnS78kUs1JmGBW1wq6wErcMXE1j7OH8HFn58t41Rmu+CKehwr+BFdMtsFIlr6xkxX/uxITj5cgllBibN5IFnKEU+rxZIqMqbmX58nxcP34JW8o8N0IqyDOkfTg4MQIdhI3ijVxEWcSuu6vJYgE7zOtV5vTwOr8T+XIJjg5xfkQ4UeSsvWu66SvjOhqaQxHXPN/o0lHNl2N+Jfu9kC8erl7K1Rz1OFZubuQLc0yDdDgQ9Jy1leak5bys56BiQRQKwegqd4Ge2MEbF5Qv8wb2ooXpIibF/ffSzePlnTgabVL5uOAhzRiUcP/FG2qinbb7TJpJ324sPTN//C8hvDtjYNYK6UhdUE1hXv2EBZQyJoPFqnFkmnyWTb8qzZWBOhEBFEdfKzEJPuOPPYgqCWMHBY5Im0UnYy+J1klWAkogLovWDPScJwM8yc5OGxDCiBu9D71dJttrbzDWZ2VuAjkJ6m9YQotE49DEjIti3ejxtxQ036Wdz8PSKUcQD/Y8oxvxxcm+f4p/9ZbKFWRZ2Q5VojRk6wjm8Wpynv J49TOzfs uX5fWxpKneIDW461GqCVJhL5ETX0ZVSgGsGVKdX863WOFOj1ibFx4HPC/1Min0RYixs73zbS3JZIHa49lfpOQuqcB8Tn4SUOgpKz/5RLGrFY0Yaq8PFDeoY0QSQ6hlmc9CpEdr+xKmOt9fpTFe50IXVNxq3EFyUGaMI13DtLgptBdnarYWDTnWDspfo/mhtp+Mw9H8q8tZRyHWjsma/yaOJ87n1BG6T6L4YTr4PYZeL57TM17o8dpUCWATP+GyH4OZZYY988MUiSKP5+WMjjt96NT21UJD1T82KU0ymn2pSm+ETH8qgGM+t3ZsYqXN1r8YnmSs1RZQLPtOAndDZ25TT+om0LzmphXwVu33fHO5BIOSVoPvipHHBSFRmYGaPpRlY7t/0k4g9otcZursyFQLJ/buhG7MFZ8LdO69Bt70ISyJa39/7NnqxqPZiiU59m1EbPFLoCeMk6xwX3h3YbDFrBlNDDpsbNqD4mrvP7ycSruaIubJYHc0Ktb1WzGoezakS0ypsuYz2/38WZHHwowxIMluQ/J1xnY/zrXYIbdbbw8i7g= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000007, 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 Fri, Jan 17, 2025 at 02:35:18PM -0500, enh wrote: > On Fri, Jan 17, 2025 at 1:20 PM Jeff Xu wrote: > > There are technical difficulties to seal vdso/vvar from the glibc > > side. The dynamic linker lacks vdso/vvar mapping size information, and > > architectural variations for vdso/vvar also means sealing from the > > kernel side is a simpler solution. Adhemerval has more details in case > > clarification is needed from the glibc side. > > as a maintainer of a different linux libc, i've long wanted a "tell me > everything there is to know about this vma" syscall rather than having > to parse /proc/maps... > > ...but in this special case, is the vdso/vvar size ever anything other > than "one page" in practice? x86 has two additional vvar pages for virtual clocks. (Since v6.13 even split into their own mapping) Loongarch has per-cpu vvar data which is larger than one page. The vdso mapping is however many pages the code ends up being compiled as, for example on my current x86_64 distro kernel it's two pages. In the near future, probably v6.14, vvars will be split over multiple pages in general [0]. Figuring out the start and size from /proc/maps, or the new PROCMAP_QUERY ioctl, is not trivial, due to architectural variations. Trying to construct the size from the ELF header is also problematic as that only contains information about the vdso code. The vvars are mapped before the code in memory independently. A dedicated interface like a prctl() would be actually reliable. Or theoretically a function from the vdso itself. [0] https://lore.kernel.org/lkml/20250204-vdso-store-rng-v3-0-13a4669dfc8c@linutronix.de/