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 26C04C021B2 for ; Tue, 25 Feb 2025 15:06:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 37BE76B0088; Tue, 25 Feb 2025 10:06:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 32C6A280001; Tue, 25 Feb 2025 10:06:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 21B416B008A; Tue, 25 Feb 2025 10:06:23 -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 0FA7C6B0088 for ; Tue, 25 Feb 2025 10:06:21 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E379D818B6 for ; Tue, 25 Feb 2025 15:06:20 +0000 (UTC) X-FDA: 83158792920.13.8F0D80A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf16.hostedemail.com (Postfix) with ESMTP id 0103C18001D for ; Tue, 25 Feb 2025 15:06:18 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZjmHLl4s; spf=pass (imf16.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740495979; 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=ulSlGShANn0qabJ6PwZZ9yBHZeUtO9LZVEnKl8528tc=; b=o+GYwY7miKZzM68r8Zruhafj28HzUkb+ipHu5YqwbyCCmuf92iFwPOyL1JlLmduj41LnU/ 0axKvO+JyLFBkzLDvUR4Mh2uAra4+kFQcD1AcdJ11DGnaHR8S2LK+99EDCzOckEfkYYh8u HmDcmFwEJGfBJSn7KAmpHpejaGNEfGM= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZjmHLl4s; spf=pass (imf16.hostedemail.com: domain of kees@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=kees@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740495979; a=rsa-sha256; cv=none; b=ERhqqr+yFjxwiMmpTOT51L3L/iMAwRKX4HtwutkASb5xownILzdMA+lnkzrsgqZ5fuMaBw AEHHmLmzwdrvul+Bgn/d7aVM3DrqiPBsaelraaWyuPSImrXryMKhGDH0HxaEuOWTaeay4t paXdDAk9c8BJGuOPyf8kUvm9K2ZCR80= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 79B545C70A7; Tue, 25 Feb 2025 15:05:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E570AC4CEDD; Tue, 25 Feb 2025 15:06:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740495977; bh=ulSlGShANn0qabJ6PwZZ9yBHZeUtO9LZVEnKl8528tc=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=ZjmHLl4sZAOy1F8GiI8E8GAiKPa5p7MSwqaQtXxYzGw1lXbbMPoC1vIM1vTXHDE1C c4lWCmbEi/mIYjG1s4rOtAhvqeyyd4jEDGnnNnVa5dB/fp/Khy1h5TlavXOdDIHJiw oHx4XaWEPVB0jlViX7Qc3tpS87j0ppDz3TW7gEKsJB0zTzwIGkCbXftF7ysnFKwGs/ hurOr1uaJZ1iNMf8vzSXGfLRCZHAZrYRIrmX4uhh7pr4zKPTfmOrOoSaDw7jhMBx6G tYSI1/1WAzzP4TEugmX0mOEYpTLVWOfCvWoOzvnpEDsMDKp/nZyTIv5/is/Sn9nMgy jrwQZeOmBeQmw== Date: Tue, 25 Feb 2025 07:06:13 -0800 From: Kees Cook To: Lorenzo Stoakes , "Berg, Benjamin" CC: "jeffxu@chromium.org" , "Jason@zx2c4.com" , "adobriyan@gmail.com" , "deller@gmx.de" , "gerg@kernel.org" , "anna-maria@linutronix.de" , "davem@davemloft.net" , "avagin@gmail.com" , "mhocko@suse.com" , "enh@google.com" , "thomas.weissschuh@linutronix.de" , "hch@lst.de" , "hca@linux.ibm.com" , "peterz@infradead.org" , "adhemerval.zanella@linaro.org" , "linux-kernel@vger.kernel.org" , "ojeda@kernel.org" , "jannh@google.com" , "f.fainelli@gmail.com" , "sroettger@google.com" , "ardb@google.com" , "jorgelo@chromium.org" , "rdunlap@infradead.org" , "mark.rutland@arm.com" , "Liam.Howlett@oracle.com" , "vbabka@suse.cz" , "mpe@ellerman.id.au" , "oleg@redhat.com" , "willy@infradead.org" , "keescook@chromium.org" , "peterx@redhat.com" , "mike.rapoport@gmail.com" , "mingo@kernel.org" , "rientjes@google.com" , "groeck@chromium.org" , "linus.walleij@linaro.org" , "pedro.falcato@gmail.com" , "ardb@kernel.org" , "42.hyeyoo@gmail.com" <42.hyeyoo@gmail.com>, "linux-mm@kvack.org" , "johannes@sipsolutions.net" , "linux-hardening@vger.kernel.org" , "torvalds@linux-foundation.org" , "akpm@linux-foundation.org" , "dave.hansen@linux.intel.com" , "aleksandr.mikhalitsyn@canonical.com" Subject: Re: [PATCH v7 5/7] mseal, system mappings: enable uml architecture User-Agent: K-9 Mail for Android In-Reply-To: References: <20250224225246.3712295-1-jeffxu@google.com> <20250224225246.3712295-6-jeffxu@google.com> <96ebddf3fe31353c89f6a4680eaeb2793c25cd09.camel@intel.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 0103C18001D X-Stat-Signature: 7s6x17nu1kwn954yq6fdtxehdpdj19fc X-HE-Tag: 1740495978-711201 X-HE-Meta: U2FsdGVkX189njnW5WMaaHEQkNXfJQJHf7EiE6weX5trh979wN8WludCcwZA21++7zLlii3Ok8haJhMP+VG4SFGUucAlBbnOLIgn1CFyH/h7MejtdyGwe4qJKTw5YJYR7aI3TCUtdnjkpvFt9sF/FlSzHVaPI/486J98+BKMEkzslM4t8xx+l4ghKSCmgcCQQ2kvOsibhvv9RaD+MwtoR816+rgOWhjZp02lW2QFwmb2HJOBxG1VqHPg9j4rdFu7227BXImqq2YC0cwYZyV4VvsvyyDpBeDFsjiARbjUglM8jLY4mFwc4oHW/lX6aqw/k92cBdvyIj90BzA+91z5FF1BSeeZN4N+7CuEUXPTPX6tlp3kXFa01ZaOX56JXs7bIEQ85Xm+/96wM+Ym99+5XkWpG2CbnGtsIVY0/Z6mG2qsF4IPlC3iCHcKna/oDpAcHDYO/Z1rDJUbYoC0tCeqV93yowo6NZv9siIQjOYQ2Tt3hewyQ9ItzaAqku2a/ne2GJtF9/tjQJWM8F7RCY285Y3D0MdmL5G9jPXkZGF3x74vt1qBOV5MjVX2xdduBBPOcDJbxJw31SzXahv11/8pvdWr4svWL+buRx/N2YVe4XwTuaKrT9HUw7oDiUNKPUHjONyP4eDdYPkZ+oZxL2ZOkiMVHFw2E8f44k61BJac7lTBWG5TGvh+gudgp0ZfO5JKZlgMdSSKREky62bAwhXpFzLE33QZ0IFooIiFpEOAqIB0w7DP+xIkc9Y2tp3w8B43OcAcry8qp9oouoSqxcGlNi2s8EIfhZLYdnPfjxXlh8b+iT7jZyIAzK6w83wIR7b0e/gjcUhvmHWnZuEiGwTwGe8CLOhl3fJETveM+iYThZJTCfYzPNqyeqhQmmKU63l3/mHSCv+ZidByYFNi9w5ccr/aek/UmmrrsmdccKypEKUGd+zrrb10YMZR6fXJf+mmdt81XLgpNhDVpkJUYxh 1Ot1qldn 41uFhTZMwsV+hvFCXwCBwuXXezpSDBBji7MbEvfCz/1oJPYkLt9Y8ntUWqptGwPIfj33hEKMHgbjc801yF/AMbiBLZZtt4d/SW9pSS6rVmlzsBcMqF1d4TEFRdJJeKXsEI8bisx9LOQuMqaPyn+raIvNwCyJLtKMSAHHzZQfn7ZU9D1GNQqzUcrsUu5LmH2rgRZbO7swj13bKZeE0AhUlCWuaLtTfbxl738todNn6uMx/cm+tZciRQFR8XWxkoei9d5EsESKSNuUW2zzRBOwlC7dXUF8uCuQipC5GZ+Su7cBqp3QCTf4Mt5IcBSad3vTjXtMWNPV26/Cau+zxJaaEPS7589QMt0DOuRxFO3R+zaDq4bMRkzpg4rCouZLcWwi/Sf9C X-Bogosity: Ham, tests=bogofilter, spamicity=0.000706, 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 February 25, 2025 2:37:11 AM PST, Lorenzo Stoakes wrote: >On Tue, Feb 25, 2025 at 08:45:21AM +0000, Berg, Benjamin wrote: >> Hi, >> >> On Tue, 2025-02-25 at 06:22 +0000, Lorenzo Stoakes wrote: >> > On Mon, Feb 24, 2025 at 10:52:44PM +0000, jeffxu@chromium=2Eorg=C2=A0= wrote: >> > > From: Jeff Xu >> > > >> > > Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on UML, covering >> > > the vdso=2E >> > > >> > > Testing passes on UML=2E >> > >> > Maybe expand on this by stating that it has been confirmed by Benjami= n (I >> > _believe_) that UML has no need for problematic relocation so this is= known to >> > be good=2E >> >> I may well be misreading this message, but this sounds to me that this >> is a misinterpretation=2E So, just to clarify in case that is needed=2E >> >> CONFIG_MSEAL_SYSTEM_MAPPINGS does work fine for the UML kernel=2E >> However, the UML kernel is a normal userspace application itself and >> for this application to run, the host kernel must have the feature >> disabled=2E >> >> So, UML supports the feature=2E But it still *cannot* run on a host >> machine that has the feature enabled=2E > >Sigh ok=2E Apologies if I misunderstood=2E > >Is there any point having this for the 'guest' system? I mean security wi= se are >we concerned about sealing of system mappings? UML guests are used for testing=2E For example, it's the default target fo= r KUnit's scripts=2E Having sealing working in the guest seems generally us= eful to me=2E > >I feel like having this here might just add confusion and churn if it's n= ot >useful=2E > >If this is useless for UML guest, let's just drop this patch=2E But on the flip side, it's certainly not critical to have UML supported=2E= I guess I just don't see a down side to keeping the patch=2E -Kees --=20 Kees Cook