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 88942C02194 for ; Thu, 6 Feb 2025 15:07:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 14996280005; Thu, 6 Feb 2025 10:07:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0FAB5280001; Thu, 6 Feb 2025 10:07:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E8F4D280005; Thu, 6 Feb 2025 10:07:36 -0500 (EST) 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 BFFCD280001 for ; Thu, 6 Feb 2025 10:07:36 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 46EA9C1153 for ; Thu, 6 Feb 2025 15:07:36 +0000 (UTC) X-FDA: 83089848912.13.3554AC6 Received: from mail-oo1-f54.google.com (mail-oo1-f54.google.com [209.85.161.54]) by imf19.hostedemail.com (Postfix) with ESMTP id 1FDF01A001D for ; Thu, 6 Feb 2025 15:07:33 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Y84w5mkx; spf=pass (imf19.hostedemail.com: domain of enh@google.com designates 209.85.161.54 as permitted sender) smtp.mailfrom=enh@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=1738854454; 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=ln7CduGbwmeps6xewZjODTeTSRHoiy3XnCU1Nuqmqw0=; b=mpf8Pv009x+7brkc2qFsruHVI8zvCkHbrv+pyu21Va+tvUIf9ecpz64bDKW3/EkaiVmfnV z26xAOiq9o+M3lSVddoxMua4sHmO/KMhugNmlPigH5eGrBvzKJ5MyZ/Mj2HFrYi77FfWB1 vqmPTrzmlhVtGFgHbpa1U3Tt2LZdtl8= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Y84w5mkx; spf=pass (imf19.hostedemail.com: domain of enh@google.com designates 209.85.161.54 as permitted sender) smtp.mailfrom=enh@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738854454; a=rsa-sha256; cv=none; b=7vPZHB13VzVoRnDs0IF6CkcOp7GscGRuvw02QD6Xif1JlKzzZTVmE54PU5yMgc65rT2pK+ JVUQ+cu+0NzxiHHRKBwEAnjgJ6FRohj8HbtOT7o2b/7mzD3rsh8qvlxaEIr3Fqkt5TGZjc cIfxhS9oIrllNNOvJ7vBGzit+FRaTBA= Received: by mail-oo1-f54.google.com with SMTP id 006d021491bc7-5fa8fa48f30so774854eaf.3 for ; Thu, 06 Feb 2025 07:07:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738854453; x=1739459253; 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=ln7CduGbwmeps6xewZjODTeTSRHoiy3XnCU1Nuqmqw0=; b=Y84w5mkx2vxRhKLSLyJUpSyFUbboG0DiJIvy+mSiaqj1PJn34ZMVKWQpD7RLRjtbpR zPKRdEe6Dl/xFPmFgxcT3KUt/FP2urrMYl/kGibT82nxYNLXt35ypneXXHpnJFH0jjSz w/qApEnMPtLYd1cUkGGHwx61gRGNIZ2FsB870LktZL8uBq7fvHlrPqL/z2EY2bLHIxsW Wa6pemqPTKu7VvnCTQMlRimUBhC0QBk02f2CpC2TirHnlU6S3slxcUsRJXvnOMPW4Ci6 ejVfDLIjELQS2R54+qrcLGB37D/r8IT+BmkuhG8P+5qJVlIMjWxiWYciqSYIO8bqE+sm mnjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738854453; x=1739459253; 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=ln7CduGbwmeps6xewZjODTeTSRHoiy3XnCU1Nuqmqw0=; b=dsHUdHU4n5A/cannfBJDuo3JJxEqAVRWoYB8C9OSYWWBdwsWy44lG8goA5xvB+Ihh4 i2XqClpz77//U5JaWb0pzhu/k9b5LxQBsPdd7lzjmp26w0fQZKSL1v+Kk4eqf8T0zL9H y5ld3Ef5FKYCnkRpGGMKgOUlUSfzCGisszxgTkzfmoidxBOxJLeHdCIc0K45M4zpjBWG UySnf9HYfBCvv0uh4Jr16b2WMuolBIWnTrEpL4sCZXoUa8EqY5MiVl5gPaxU403THXhQ 0UdJWAtUJsvSdrcNJ7K7Wsb9xruvT9/ulUfuloTWvHqarm3unuINCIktfPSe9WLek3yM dZsA== X-Forwarded-Encrypted: i=1; AJvYcCWxfexV1vBzXvLpiHkfQTtMEN4hsW1z4cC1p+VLRApGaJjPgK0+wBryKZJ0QHLN8ClIfZXXfyQY6w==@kvack.org X-Gm-Message-State: AOJu0YyxVca3knPCzoCQ4yEtv4/rvpaUXLUYe/4/LiA6/K37zVIqwVv1 L7b6cq/nkVkBkY2LGfLpVcpyrXVqoNzEVSSo9zn7IhfCCOnYwIthZh7+7lIeZ8qiPC0G3ZilLbJ Rk4Jx0PDeCBoWwFu5siAEuYIq/JvTcogXBkaA7UHrq5Vy8A8FsXt2dic= X-Gm-Gg: ASbGnct8+iGFFeG0tRN0TfEwG/p088BhGL5LwLwCFkZQBblJuAzNos0Jl502JLbNga3 4Pq9uMHI8FqKoP3cTYkcOQJgpNQ//7+bCRJjusHzRQw74EpIl/2D7QhFgRnwNd8bSzr1cTw== X-Google-Smtp-Source: AGHT+IEiPzusdtphZUreBnjsbY0+PMt66E5dhy1spQtF9N92lQKBk9LL4fqd8V6EFSCa0caZ8WuX8ysfWKJ9JRlntZ8= X-Received: by 2002:a05:6870:eca9:b0:29e:630d:bab8 with SMTP id 586e51a60fabf-2b804f903d3mr4612630fac.17.1738852750772; Thu, 06 Feb 2025 06:39:10 -0800 (PST) MIME-Version: 1.0 References: <202501061647.6C8F34CB1A@keescook> <5cf1601b-70c3-45bb-81ef-416d89c415c2@lucifer.local> <7071878c-7857-4acd-ac27-f049cbc84de2@lucifer.local> <2e5de601da34342d8eb0d8319dcf81ff213c7ef0.camel@sipsolutions.net> <20250206135150-6c770e7d-9af8-4924-b760-82cff5092586@linutronix.de> In-Reply-To: <20250206135150-6c770e7d-9af8-4924-b760-82cff5092586@linutronix.de> From: enh Date: Thu, 6 Feb 2025 09:38:59 -0500 X-Gm-Features: AWEUYZnz0jxlopnKdi7ztUNgOKau8bLEUw1_NjCXJu4QWfY5ioWB_j3DZMscb1w Message-ID: Subject: Re: [PATCH v4 1/1] exec: seal system mappings To: =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 1FDF01A001D X-Stat-Signature: 5nszm5yikr49bezmsqzyj7jm8ah11u8x X-Rspamd-Server: rspam03 X-HE-Tag: 1738854453-431709 X-HE-Meta: U2FsdGVkX19mBRG+XudHxzixzrKHSdZ0uTNQudoXA4WE8XhYrRdVdPP3H+RnYVdQo7mWXYdzYTDRzsz6TsJouZgq2A6TTwtpEYXp8s2rjw0auPPwDidIeJK0IQf4+Acw6mz1tn02BwxCiE0pzGi6S7JySN3aV7E7AzsiVvWKneADT5MXQebFDhK5AdN3maFl8go1FhBEVmwWtdsifUKnAN9ldhsZvWKA98RoBNfw9m9wmavPp/bBGNqSMq3fvAqhg1k9xuQzewC9HE/M4SGWWCyJ2QFUol+17up+a/gZuv/+HyRG04CrudJar45b4R0QdGKLEPNSH+vQ1lDf0iVWGBO8JrreVgRK9L3ckLU5itNreMI9apcaY32JjUYSptmqLoYunjNPnc2qnHh7I/qZmgwbLzMaH5ZM7YQY4pTnE2mSAoM0I92vi9R8rRTccpO9Y6Fq10EAETElmVShhyDABPQz3mJt66QAHbAT1za+i5swp6OpgxZMGIQswNNJSpXaf1b5dCc8wlHM48viJi7/DK7ywdCqO/Cj8g5ku5tMg0ngfyI1HvImGaAJUbRca7bFwtdtNM/y40MkYJ0rU1DQr4YDGMiGaeyEqvBtKpOvKRjHn0CHzWoy96JClGrM0UIMEEbkfHFLGRwszrDNPvjXG8+EFSVWWjUgq8711h2vrZpahjZP4mOtSIgYfUYVCNUQw2nY8nv/6s+JzgmuRWlAlIWh7NO2dlpCGZGD4xbSthAuxgqYX2EJIFUb32ZMPZsoykAv/j5JpjreOBNBem9br1/IyBh/QfoiuUY1yTKHdP2jrnXwOXPZUZsaLuWImHWHz9yute69O9I1hUfMJNxVXC2qnBE4w2Cdon/465gEB9ewmp31amPM+d92TkXWvKLzac0KJI5LLJJLBJvo0mSD8HlX4FMmjq8UJ2k10/tZom1hhDbgX6jbx1eZml0KbSfda8Y55Bx8FP08+g+iMVQ 1fmXAE1W Ebgvo/F7kT0lZfyjgDeV9Do5OGmj5opP2xvvNV6F/TqgsVTbnlEAvkrO28maPTiXBYOkk7uPSBtV/nVo7dZMpJgyYo7Qrsg4d+J9ptf/G2ofW7WMvXsOCElC+wApDYwgHv09pGN1+hD0suhX/BdB1TPS8KbKYRere7uS3uw0B1WYfMhq8PIpvu4S/sam1IKWIdLTSIwmE+oOM1IM/3pLONumNsN461kYQZyhJ04kFKSS/30OqSP9Z9QpH85tiGXsupiZnpCNzk8olUsbso37GaDvzqwe0d/jwzguK8W4w7RcI7Df0ywE9VECZDQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000065, 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 Thu, Feb 6, 2025 at 8:20=E2=80=AFAM Thomas Wei=C3=9Fschuh wrote: > > On Fri, Jan 17, 2025 at 02:35:18PM -0500, enh wrote: > > On Fri, Jan 17, 2025 at 1:20=E2=80=AFPM Jeff Xu w= rote: > > > > > > There are technical difficulties to seal vdso/vvar from the glibc > > > side. The dynamic linker lacks vdso/vvar mapping size information, an= d > > > architectural variations for vdso/vvar also means sealing from the > > > kernel side is a simpler solution. Adhemerval has more details in cas= e > > > 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]. /me checks the nearest arm64 phone ... yeah, vdso is still only one page there but vvars is already more than one. is there a TL;DR (or RTFM link) for why this is so big? a quick look at the x86 suggests there should only be 640 bytes of various things plus a handful of bytes for the rng, and while arm64 looks very different, that looks like it's explicitly asking for a page (with the vdso_data_store stuff)? (i've never had any reason to look at vvars before, only vdso.) > Figuring out the start and size from /proc/maps, or the new > PROCMAP_QUERY ioctl, is not trivial, due to architectural variations. (obviously it's unsatisfying as a general interface, but in practice the VMAs i see asked about about directly -- rather than just rounded up in a diagnostic dump -- are either stacks ["what are the bounds of this stack, and does it have guard pages already?"] or code ["what file was the code at this pc mapped in from?"]. so while the vdso would come up, we'd never notice if vvars didn't work. if your sp/pc point there, we were already just going to bail anyway :-) ) > 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-13a4669dfc8= c@linutronix.de/