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 BA2BCD2444F for ; Fri, 11 Oct 2024 00:53:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2608B6B007B; Thu, 10 Oct 2024 20:53:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1E91A6B0082; Thu, 10 Oct 2024 20:53:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 089AC6B0083; Thu, 10 Oct 2024 20:53:15 -0400 (EDT) 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 DDD046B007B for ; Thu, 10 Oct 2024 20:53:14 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DA7C41203E4 for ; Fri, 11 Oct 2024 00:53:10 +0000 (UTC) X-FDA: 82659497466.08.828AD69 Received: from mail-oa1-f41.google.com (mail-oa1-f41.google.com [209.85.160.41]) by imf14.hostedemail.com (Postfix) with ESMTP id 7C165100008 for ; Fri, 11 Oct 2024 00:53:10 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=TkPUgHlr; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf14.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.41 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1728607891; a=rsa-sha256; cv=none; b=68Uh4sxUKHhjSNIxz40nLHALXW/J77BjEk2rY6ckue4g4866CbooCvTMffP36LUyFF9wgS 0SHMU2KMYd5jrYF2pX3WNBvbvl4VihthFV9kC5ml6iKoBKlc4UasLVagmkJ5Ce/SYWjPLl x/n8hfJzrPJsv7zld46SlrrPKFjWXfg= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=TkPUgHlr; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf14.hostedemail.com: domain of jeffxu@chromium.org designates 209.85.160.41 as permitted sender) smtp.mailfrom=jeffxu@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1728607891; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=HLwtLwPuWAh2naPHwodMzmTHRgXKo38Ia3bfbc295cY=; b=1lFcYmojB+SBi7rKgGFQRXHnQA9WDJC1IXbQhElGBIDcok+oSmyFmipSLpqTdX8wHzD7y4 QY6mYqtJuRtaqmefN3+nEhGI7BJLRYCivOYdQcn0rK3MGmikyD0GbV4Sa4bTgh14UALEUH vYivyptK6aFyk5HeuzNn9+a0pE210Oc= Received: by mail-oa1-f41.google.com with SMTP id 586e51a60fabf-287fc54c6fdso111909fac.3 for ; Thu, 10 Oct 2024 17:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1728607991; x=1729212791; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HLwtLwPuWAh2naPHwodMzmTHRgXKo38Ia3bfbc295cY=; b=TkPUgHlrXtf8qE7AuSU0Skixc9hNdDXssf+x5DHFbxWsZ81NpDMUkcIseaDkryPdFA f3e/K9wMMiC0HTGLQvmdw4ZMdsdZipsl8jENTILjl1IH9TmPmMAc1u6ttGautYogtz1q oQUsbHTHmzWMKYtyP7Wki0Qry2WyXzcEgTQ2M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728607991; x=1729212791; h=content-transfer-encoding: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=HLwtLwPuWAh2naPHwodMzmTHRgXKo38Ia3bfbc295cY=; b=IQHMKAfd/oIdvH92YRjjck3msaU72yhPWv4qLq52D2uRyxF24+hwTRMpt2gylahxXi Sx/fcdLuzTM/NW3iW1DJrjxPAnt1Ln2JRp/imC17+LZ2cC3gr6cIm4TtFyV8qIk3VvkY cAWtzVdUtFiMuHEhb0TiCOUIh/xNuZOrRNAeDUevBEFKScqGd+JgNp0aLDWgBttLZnaY fHfvVw4CJggNjXY/XwiAPh06pBVNljKbXzjivMkIhT/WZlYwrxjsMgsq4Uy6qyFWBO0g 7BfBAWGsPA77Z5aF2gisUlSJU2hL0X1UH2fX+XbPn6qcoHU2tUfFXuEXK0SSOrsaLoEJ 4+XA== X-Forwarded-Encrypted: i=1; AJvYcCUM8tiOGN21VzFMwcWZMYF5L06xbxDXBI9RpAhhiH0YpFUnviVHqi0IUcpTvtMv/M4H+MAX+ux7uw==@kvack.org X-Gm-Message-State: AOJu0YxxwQs7J93bEOntLmsqamp6TebecMvqebPW4kxGEnjQSDCWvGyY xWa5fBTDvB3WZYkWTcW0Whfw0Khhv/ubgn132dNtRNNitLR1j21yuxWGGO3BHh2mcng5CZyShXm 2t5xQKbiKQwUJrngsAR7UAvKZkCUqbEuEzWiY X-Google-Smtp-Source: AGHT+IEwQwEkKiBKgeuxW+aagIyAxDVRfVgQJV6rvFsVR533kn+LASZBvPvFX5vGVB5b/t6IcNwX52l/azlKAJArvRQ= X-Received: by 2002:a05:6870:171a:b0:278:2698:7721 with SMTP id 586e51a60fabf-2886debba73mr180660fac.8.1728607991573; Thu, 10 Oct 2024 17:53:11 -0700 (PDT) MIME-Version: 1.0 References: <20241004163155.3493183-1-jeffxu@google.com> In-Reply-To: From: Jeff Xu Date: Thu, 10 Oct 2024 17:52:59 -0700 Message-ID: Subject: Re: [RFC PATCH v1 0/1] seal system mappings To: "Liam R. Howlett" , Jeff Xu , akpm@linux-foundation.org, keescook@chromium.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, mike.kravetz@oracle.com, 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, nathan_lynch@mentor.com, dsafonov@virtuozzo.com, mhocko@suse.com, 42.hyeyoo@gmail.com, peterz@infradead.org, ardb@google.com, enh@google.com, rientjes@google.com, groeck@chromium.org, lorenzo.stoakes@oracle.com, Jeff Xu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7C165100008 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: rrfy71ds9me6np6q3ysfyfozm8c3zyjo X-HE-Tag: 1728607990-262990 X-HE-Meta: U2FsdGVkX1+3oi7fksBP7y+wOe3/L5vv/JMYKs5RAwIxljPl2oJRA/5+UHtzz7U3xvhM+SdNyrzAeWwScFmPO1vROeN3BMmKeFc+cqKK4/SuN85wodWe+Sf5Iztj4VkRjmIwXHvTmEowLIW0tCk/OeKzIWAd76Ybj7y1QfKnGdZJskXssqVT3Xvvd088H8UUGva7Fpp8+en2LTpS1PNfmN4+m0ku/3S4lr2mm5S3oKND2pDemSBP4uWV1QdDr3r1FsvkZ5ASG9I1kj5ypMrynGvhXjssiQLyl8qD99WfLZF/wK94DKSsmAcN/lZsMasdhvyYP+OGJYnINfuDXxly4wK2gJaXa6UzCqq0Axa1C01xQnUk143zfkxnQoeWTRVVhUsbqQSCNJXtc4rXwksEg/u/kAwdYboOu+h5Wb8kVBQZet+pKXYoHYgWspucOcrm0a+kSR7YSbSe26pkNXMOJw1wt12Jiz08cbVe5WjiyQm50+lA1uON/P8o/kSQLrXPoQ6J22MXTu3EqXnLg0/SErgWm/ze9lhb1ImtkXht2vCOn/M7E1WAE8rBfXrTCfdtGwf8zULSxCudgBluiw654r2+vm3gseBp0YE/7plamP01Ra1pHPL9G5NVa7ajMGzmXOy4360zZq1vf6AKlsW9r+bE8stAPoJO6qcrz1Fx8KuvW4hIk3xtY6O8jzLj7PihogbHRqR9cdUASKWqNPCJ7yjulYZqFryHjJl4isiThaXFYyKkOZxCmrTbgcS4V35+6WQfDYNFigmzBcf4UbVPZgLdWVKKgPS/IZKR4JDZlRw4KIt7WMpkL04xM3Mz6y4tTWGOjLtAuBvwrt6SUPaOTABc+e9N/fvHZTVJIwgM53Vu5EvW76lNSe3ceTtiHoSMjQgueq5WHN7cBzp3e/cyjh5PZqo/hyvI7YfQfaHON+oNlRCUbkGGx7EAT9TBa3hX5Y9roOLwPrVNlp1D4oW 7JPVS/ov 3qbRmxO5wm9+nWSJUrszwqLDAdRj31+mlkXvycBIvTFxWZ053t+BHkC/K5uN6iGPkumbN9gWKtT9gBWkbZZqrXkZ/LVhO4FGP4fCng6f+7spYx/pbtrHPsaSVkCgx2HB/O+3a7DC7Yvv8FpectI9ebFCK6JFccvbFZv58Yae2a5GsOjdJYS/82lPGDR8qP9HztPb91v5Kzkctp9xCSfa0eoRv1tBylOu8OfMK1KYf//XcpD2LLxCw+deaw4iZFjVOutHYS0YoxgR/L7OkIOhQ1sCFLWvTueUfDmTQZGuyLr3FpMkSy+imkvZq1KqdLkFJt2e0+xl4RC0ytoXvoXFWH62VDQekjtzPSheRF/6KU9xErE+3x30rE75XfS/K0/sqc2OSgvBWs3dgW/U= 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, Oct 8, 2024 at 5:42=E2=80=AFPM Liam R. Howlett wrote: > > * Jeff Xu [241008 11:01]: > > Hi Liam, > > > > On Mon, Oct 7, 2024 at 7:19=E2=80=AFPM Liam R. Howlett wrote: > > > > > > * jeffxu@chromium.org [241004 12:32]: > > > > From: Jeff Xu > > > > > > > > Seal vdso, vvar, sigpage, uprobes and vsyscall. > > > > > > > > Those mappings are readonly or executable only, sealing can protect > > > > them from ever changing during the life time of the process. > > > > > > > > System mappings such as vdso, vvar, and sigpage (for arm) are > > > > generated by the kernel during program initialization. These mappin= gs > > > > are designated as non-writable, and sealing them will prevent them > > > > from ever becoming writeable. > > > > > > But it also means they cannot be unmapped, right? > > > > > > I'm not saying it's a thing people should, but recent conversations > > > with the ppc people seem to indicate that people do 'things' to the v= dso > > > such as removing it. > > > > > > Won't this change mean they cannot do that, at least if mseal is enab= led > > > on ppc64? In which case we would have a different special mapping fo= r > > > powerpc, or any other platform that wants to be able to unmap the vds= o > > > (or vvar or whatever else?) > > > > > > In fact, I came across people removing the vdso to catch callers to > > > those functions which they didn't want to allow. In this case enabli= ng > > > the security of mseal would not allow them to stop applications from > > > vdso calls. Again, I'm not saying this is a good (or bad) idea but i= t > > > happening. > > > > > > > > > > > Unlike the aforementioned mappings, the uprobe mapping is not > > > > established during program startup. However, its lifetime is the sa= me > > > > as the process's lifetime [1], thus sealable. > > > > > > > > The vdso, vvar, sigpage, and uprobe mappings all invoke the > > > > _install_special_mapping() function. As no other mappings utilize t= his > > > > function, it is logical to incorporate sealing logic within > > > > _install_special_mapping(). This approach avoids the necessity of > > > > modifying code across various architecture-specific implementations= . > > > > > > > > The vsyscall mapping, which has its own initialization function, is > > > > sealed in the XONLY case, it seems to be the most common and secure > > > > case of using vsyscall. > > > > > > > > It is important to note that the CHECKPOINT_RESTORE feature (CRIU) = may > > > > alter the mapping of vdso, vvar, and sigpage during restore > > > > operations. Consequently, this feature cannot be universally enable= d > > > > across all systems. To address this, a kernel configuration option = has > > > > been introduced to enable or disable this functionality. I tested > > > > CONFIG_SEAL_SYSTEM_MAPPINGS_ALWAYS with ChromeOS, which doesn=E2=80= =99t use > > > > CHECKPOINT_RESTORE, to verify the sealing works. > > > > > > I am hesitant to say that CRIU is the only user of moving the vdso, a= s > > > the ppc people wanted the ability for the fallback methods to still > > > function when the vdso was unmapped. > > > > > > I am not sure we can change the user expected behaviour based on a > > > configuration option; users may be able to mmap/munmap but may not be > > > able to boot their own kernel, but maybe it's okay? > > > > > The text doesn't say CRIU is the **only** feature that is not > > compatible with this. > > Fair enough. > > I read it that way since you pointed out breaking criu is the reason for > not enabling this by default, although it's probably the biggest reason > against doing this. > > > > > The default config is "CONFIG_SEAL_SYSTEM_MAPPINGS_NEVER", and > > distribution needs to opt-in for this feature, such as ChromeOS or > > Android or other safe-by-default systems that doesn't allow to unmap > > or remap vdso in production build. > > Okay, but you never stated that they can't be unmapped or remapped in > this change; just that they will never become writeable. It is worth > adding that detail in the description since it isn't entirely obvious > unless you know the workings of mseal. > Thanks, I will improve this section by adding more details on memory sealing or maybe point to the mseal.rst document. > > > > Thanks > > -Jeff > > > > > > > > > > > > [1] https://lore.kernel.org/all/CABi2SkU9BRUnqf70-nksuMCQ+yyiWjo3fM= 4XkRkL-NrCZxYAyg@mail.gmail.com/ > > > > > > > > Jeff Xu (1): > > > > exec: seal system mappings > > > > > > > > .../admin-guide/kernel-parameters.txt | 9 ++++ > > > > arch/x86/entry/vsyscall/vsyscall_64.c | 9 +++- > > > > fs/exec.c | 53 +++++++++++++++= ++++ > > > > include/linux/fs.h | 1 + > > > > mm/mmap.c | 1 + > > > > security/Kconfig | 26 +++++++++ > > > > 6 files changed, 97 insertions(+), 2 deletions(-) > > > > > > > > -- > > > > 2.47.0.rc0.187.ge670bccf7e-goog > > > >