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 E18B1C02183 for ; Fri, 17 Jan 2025 19:35:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7972F280004; Fri, 17 Jan 2025 14:35:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 74756280001; Fri, 17 Jan 2025 14:35:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E6F0280004; Fri, 17 Jan 2025 14:35:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 40BE4280001 for ; Fri, 17 Jan 2025 14:35:33 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F25FD140BD4 for ; Fri, 17 Jan 2025 19:35:32 +0000 (UTC) X-FDA: 83017948104.19.2108854 Received: from mail-qv1-f47.google.com (mail-qv1-f47.google.com [209.85.219.47]) by imf18.hostedemail.com (Postfix) with ESMTP id E4B3B1C0009 for ; Fri, 17 Jan 2025 19:35:30 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pLEjuixz; spf=pass (imf18.hostedemail.com: domain of enh@google.com designates 209.85.219.47 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=1737142531; 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=l0NSKWvLWFeR1xeLGL0GyYR3i1t5ClvvGlKBcqjteoM=; b=8i7n2vvm7XkQ5W8iDkYO5tyC0Qasp8QDCWZ0EOpsQPPDEjOXlodJk1bdyi1lhc+UQU1DOJ HuBKg7Bw22ti9A6cmBshuL2TMsWt+i1XvwKSPAvLFVD+9LikYvGQVKI+nVf0RYOuaiRHOx nowTQcKU2h4WggC/GO9qeSWWnRJGVDg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737142531; a=rsa-sha256; cv=none; b=6qOEfgeTTRjIUeoqtY8f56mumQGlK0kI4Mh5fJjhfRWFainwtmDxxOtDR0WwbxeCu1u63M 7N9JV/FNNYf1Dngt4XGKqaDTIm3zDWs10Jo8djBJIl3HqYvmdtGKVPHT67yDaa8rLGLcHM HI0ddh8k9d8YjaHcHrOnK9ekAnBN3tU= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=pLEjuixz; spf=pass (imf18.hostedemail.com: domain of enh@google.com designates 209.85.219.47 as permitted sender) smtp.mailfrom=enh@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-qv1-f47.google.com with SMTP id 6a1803df08f44-6e1a36b3684so30935006d6.1 for ; Fri, 17 Jan 2025 11:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1737142530; x=1737747330; 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=l0NSKWvLWFeR1xeLGL0GyYR3i1t5ClvvGlKBcqjteoM=; b=pLEjuixzmIsy/ca+D0lqDFgzoriLlA4r5zWJhBHhFohPw6Y7JIps3arNrF7RA09CuP Kf2erHlAtj8gE1nPkmTHeWf9QSJO3q/jH5M1n+6qaiLppmvyE7W+w8R6222YahePC3hG ave1judENFecFBcC6FFa4UHDwlSm7C86IzVVeTiZxfANLXRUOYM9hploYM6x9K8vQuLv jLnG+IY+Y210jxl3oY6U8smq4qMDbynsNeHb3k7B0eZ0+/4DR4Hh52WBbDl8Bv2279cy eR5wUMNUg1aotvZpDYERjSFlo7yzeSgf7QkQojZSbesj/ePynXtZigkhPzOMKwZqojh2 JsFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737142530; x=1737747330; 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=l0NSKWvLWFeR1xeLGL0GyYR3i1t5ClvvGlKBcqjteoM=; b=QediXVeNwe0l4vVALEoUl6dNHZkl3nIhuWcRkjptxdFDN/foMHKi7zugIeXCYG3DRC aDBKOGlf/rbI8QiFAyp/Dj+Z6rG05CumSJzJ63BkbUAkbf7t8hzin74SIi8UnaRs+K97 AgFkIZj92YjR70A1YykfMxUYM/xoFkRl8oLaCKXVaZOYVaqiOBHb37VRh50mh5Kg6K5a pnaiiNXsSdm0fJnjyFoSlvUNu06aCe7dHXAaDtAO6EKCYZrayD9ANtfKjtmd0t1vxU7f ka6n0tRuU348XEr9DfTItCZEUNXVue/L4g2y6eIV/BOp8jwbEkE96/ZuPzl62vYfsoIE YjwQ== X-Forwarded-Encrypted: i=1; AJvYcCU0SD3yUyigyMiYS8ew4aGj8xT80BjpiAaBzxmPLhKb5kUrTk/M0FPE6btsK3MXrDGEl/4RWQAH+Q==@kvack.org X-Gm-Message-State: AOJu0YxvScL0ouOsfcosZ0sUxwdmQhqxELIt8w2bECDEncG7UgyR5sQy T/KhBKG+dEcrcsTFLE1fWfipr8s76yxqjmt0iQiCQ/ZL6lN9TBioUreBaeoeBO86kEFHos2Zhtn pfsX2PIfAOVhA6n2oj7IxCEwpBEsGXQklh1Xs X-Gm-Gg: ASbGncvxg2hcLFunvKy3u/+mS1uKtGSO7t2z3kVItvkgUbyMexbNjYKcpGrn+Brrg/m 80HHPPcQ6vR7kZ4XwDfg9FYF14SE5LGHqRek= X-Google-Smtp-Source: AGHT+IEz+H9K4qcswyKJVr8f/V4dLAGWaZ2IEdJ98YGU1N84YtyCwzuFA8b/FUIFw2oIjZh1saRbCEf/T67kF78Sq4Q= X-Received: by 2002:ad4:5de1:0:b0:6d8:7e5d:ef1c with SMTP id 6a1803df08f44-6e1b2180fcbmr73609836d6.21.1737142529803; Fri, 17 Jan 2025 11:35:29 -0800 (PST) MIME-Version: 1.0 References: <20241125202021.3684919-1-jeffxu@google.com> <20241125202021.3684919-2-jeffxu@google.com> <202412171248.409B10D@keescook> <202501061647.6C8F34CB1A@keescook> <5cf1601b-70c3-45bb-81ef-416d89c415c2@lucifer.local> <7071878c-7857-4acd-ac27-f049cbc84de2@lucifer.local> <2e5de601da34342d8eb0d8319dcf81ff213c7ef0.camel@sipsolutions.net> In-Reply-To: From: enh Date: Fri, 17 Jan 2025 14:35:18 -0500 X-Gm-Features: AbW1kvYaXalMuVcN4fChMZ9gaCas0Qmcz-I2_lvsxGYgbIiFv-NPY4ujWyjJTzw Message-ID: Subject: Re: [PATCH v4 1/1] exec: seal system mappings To: Jeff Xu Cc: 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-Stat-Signature: nucwcrq1b6foq9zeimp6bztyputrj8ka X-Rspamd-Queue-Id: E4B3B1C0009 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1737142530-569843 X-HE-Meta: U2FsdGVkX19ZFyZEs2cVFJXN+mq3+okiuLmird0aMPv+HuJBLBphni7WF1GVJFQxpnai4x21fHVopa8Sih8Y997u/4WgmscAgYt08XD+5bh8Bppalqt5GukM3vpZ6LA6xAhJeHebrZn2DoLMntku0JhYXfKOdsMfZjyKu9iczsl8nfdmoKJ7fxYsGrZXWJaQ9jxBOmJ4jPEcwv9zia760wmoy7/yNT9MVQhiHnq0FOLGdYpePIM3fTcr7M7m8vserDf9O9k5Mh25JFTnHqzAZgfxojWbhuAD19cjjLKmil25LxcW3MoR45FwiO1TElAJkV+jsDYeGuMbRkJ09s22rmxhPLyjhU51gMoVqqbj8jF7YBNF+aq4mSGQVt7uz33e0pmJCodM9nOqgtQggjXxFooVSo2HMtXke/ZtdHuk2ebRuhgy9ovTQpimOJU5051dgSGoEoAVlNYhHe/owUqogVdhqwvWKKkTzItuLBOa1xpH1eAtAshCpbLczIuaO2jHzwRiRaVUqQuTD/Es/3t5o1leBLb+vf322t+fYEAORSjfF2EUvLlvkvOviebxpeG+X+elEjCGaBB9lK1/SE47TEHiycsH+sdneIGYJNJm8vQrtw7vbO1w0fbPeQrG5n9zEZxL1teurVolujfABRc+U9cNW42m3ukQ1WG5Y7k9RvXNIokWdd2UAjCO1L7ACO3n5B9oFe1jIFrW1z5A+UP1i08a877PWEtCtNneWT67BWA5HUvBf5nInC3PyfYJMkzBqucBWmZBTvWyGJX8yBi2jG2HrrM8bQnMVX4dBk2xAU1aATOlAY8HF1P2Q6mJsDfLx6JSedZicF4xzHCl3GyA8TNYTmWqjoia6VhAo2Q+0p5rmtWBiUsdS4GeR1LBaS1ePgIRZNJlXoyUPObFOCr61l75c21CCdZelI+CKPHUbY1/+YtutNZTiRIeLH4eGLShLuMOZYLalnlHrSW6E6m UuTOsucf A8m1Rb8GYXVftpgSBCbQUd8TQUdjrEOpQpPPDIJNt1duSvfFYwtJM5aihcUgWTNNwx7QXuy66Vc8U3wJFuG839XHNnAkoGPlSyzZTRECCCFPMy2uNLr65b5VrSAmqNQFGjL9VgYxEY4D3MbQnGMgbt3TR2aKpH5lJf1E9bKZ/EEJkO1RQM+pAgGTp1nNsvi7qs7LAD3/XAFSwLJaB0e4BPrxqDqbfHWLiwRDjk6sebQMAXQI7PZilyyxwSBRJww2I+jfuwktwATwQlhEOlxrKmtKQ0GIL4svzQpmW+RY2ypXr/zfpugRAyPtuA2YsnNVFRqvc+mQWr4LE5z0GvkBgLAHcHOB15iPFaJXoGGjegQxB4as85NGEr6QR2PK0Q0MDqAHKJVVbHBJBWvY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000627, 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 1:20=E2=80=AFPM Jeff Xu wrote= : > > On Thu, Jan 16, 2025 at 9:18=E2=80=AFAM Pedro Falcato wrote: > > > > On Thu, Jan 16, 2025 at 5:02=E2=80=AFPM Benjamin Berg wrote: > > > > > > Hi Lorenzo, > > > > > > On Thu, 2025-01-16 at 15:48 +0000, Lorenzo Stoakes wrote: > > > > On Wed, Jan 15, 2025 at 12:20:59PM -0800, Jeff Xu wrote: > > > > > On Wed, Jan 15, 2025 at 11:46=E2=80=AFAM Lorenzo Stoakes > > > > > wrote: > > > > > > > > [SNIP] > > > > > > > > > > > I've made it abundantly clear that this (NACKed) series cannot = allow the > > > > > > kernel to be in a broken state even if a user sets flags to do = so. > > > > > > > > > > > > This is because users might lack context to make this decision = and > > > > > > incorrectly do so, and now we ship a known-broken kernel. > > > > > > > > > > > > You are now suggesting disabling the !CRIU requirement. Which v= iolates my > > > > > > _requirements_ (not optional features). > > > > > > > > > > > Sure, I can add CRIU back. > > > > > > > > > > Are you fine with UML and gViso not working under this CONFIG ? > > > > > UML/gViso doesn't use any KCONFIG like CRIU does. > > > > > > > > Yeah this is a concern, wouldn't we be able to catch UML with a fla= g? > > > > > > > > Apologies my fault for maybe not being totally up to date with this= , but what > > > > exactly was the gViso (is it gVisor actually?) > > > > > > UML is a separate architecture. It is a Linux kernel running as a > > > userspace application on top of an unmodified host kernel. > > > > > > So really, UML is a mostly weird userspace program for the purpose of > > > this discussion. And a pretty buggy one too--it got broken by rseq > > > already. > > > > > > What UML now does is: > > > * Execute a tiny static binary > > > * map special "stub" code/data pages at the topmost userspace addres= s > > > (replacing its stack) > > > * continue execution inside the "stub" pages > > > * unmap everything below the "stub" pages > > > * use the unmap'ed area for userspace application mappings > > > > > > I believe that the "unmap everything" step will fail with this featur= e. > > > > > > > > > Now, I am sure one can come up with solutions, e.g.: > > > 1. Simply print an explanation if the unmap() fails > > > 2. Find an address that is guaranteed to be below the VDSO and use= a > > > smaller address space for the UML userspace. > > > 3. Somehow tell the host kernel to not install the VDSO mappings > > > 4. Add the host VDSO pages as a sealed VMA within UML to guard the= m > > > > > > UML is a bit of a niche and I am not sure it is worth worrying about = it > > > too much. > > > > I've been absent from this patch series in general, but this gave me > > an idea: what if we let userspace seal these mappings itself? Since > > glibc is already sealing things, it might as well seal these? > > And then systems that _do_ care about this would set the glibc tunable > > and deal with the breakage. > > > > Is there something seriously wrong with this approach? Besides maybe > > not having a super easy way to discover these mappings atm, I feel > > like it would solve all of the policy issues people have been talking > > about in these threads. > > > 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? > Additionally, uprobe mapping can't be sealed by the dynamic linker, > dynamic linker can only apply sealing during execve() and dlopen(), > uprobe mapping isn't created during those two calls. > > -Jeff > > > > -- > > Pedro