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 0CD98C021B2 for ; Tue, 25 Feb 2025 18:38:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7F5D328000C; Tue, 25 Feb 2025 13:38:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A52128000B; Tue, 25 Feb 2025 13:38:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 66DCF28000C; Tue, 25 Feb 2025 13:38:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 4956928000B for ; Tue, 25 Feb 2025 13:38:49 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id EEAC381C71 for ; Tue, 25 Feb 2025 18:38:48 +0000 (UTC) X-FDA: 83159328336.06.EAEC01F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf21.hostedemail.com (Postfix) with ESMTP id 31AF41C0008 for ; Tue, 25 Feb 2025 18:38:47 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lsw+zqxU; spf=pass (imf21.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=1740508727; 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=0IGv+qVL0MCQwNZc0rNnuEaSRg5dzo5bFI4lHFJhIvw=; b=7Q0BWS3rGzVtswXK7m/NhIOj5mrPnsS99x+vjLHyf3f9D2vLdrpmy8FOO1jVaV3SSKUozY arqSKobrWwPtEtBWAm/xShytvXxlD5uS/lB+gHGH/f7gE7ftyU6cibHX89D7+z7IiXSQ01 LJFwWS89TE0+aVApHbu4by6SrWe61uY= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=lsw+zqxU; spf=pass (imf21.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=1740508727; a=rsa-sha256; cv=none; b=p1Vav27jYkMwyBeGv+lXVjDprAEdp+DkR3akIr6zgRU2rMOBqEKw1Hvcm+AIc8gOkm7Ov6 7MfmwhAkMbsyqkymV2TzUHcu0DjOfEm+7FYsfRo3mpo3Vb7kJi8TsCVk7SjezGrVRMe3sQ qzEu4xXOBo5mD0RPbVfdQij3ArBQTj8= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 3A5265C6759; Tue, 25 Feb 2025 18:38:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B9B08C4CEDD; Tue, 25 Feb 2025 18:38:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740508725; bh=ynX2StzETqPMRv1sdJI/4CozZVwIRxYLX53PEHHkcQk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lsw+zqxUSt7OeHiW9hIjV+0jTTUXBVnq88zOOfS3hLriptFejXvqcagC8XXm6v9/R wmE1A0PgDmxavb5S3ymUTz8hqUvpNLt+elmrHdG6g9qdeT7bh0ldb05oH4fOjgsQK7 y3mR/brq8qgAi7Dd/ixnputzOLMHjwqKL4ttEFjyis2SNq+obDTVjA4XPyepDF166H KP4IR8+HE6nELDxMVnBt+y1Lfs5uUhqcHTaZfe5+eMolVV8nt9ij38REHd4DXwZzjR innyYhz6Mae3I8EdJfXBlFNOgJdi50ppuyoizxI8ItI4IvLy7UKt7thf/bZllu8r1X QsPdM3dMJ+bRA== Date: Tue, 25 Feb 2025 10:38:42 -0800 From: Kees Cook To: Lorenzo Stoakes Cc: "Berg, Benjamin" , "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" , "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 Message-ID: <202502251035.239B85A93@keescook> References: <20250224225246.3712295-1-jeffxu@google.com> <20250224225246.3712295-6-jeffxu@google.com> <96ebddf3fe31353c89f6a4680eaeb2793c25cd09.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 31AF41C0008 X-Stat-Signature: ynhanfwjc1fy1onzy9btumy4t6h9g9ke X-HE-Tag: 1740508727-380500 X-HE-Meta: U2FsdGVkX19rIrfR9io/O6HGtg248d+s2NHNhZJiQk0vTpBnb+rGmcTuVbAanGOm1+U/yTOrj5cljycLNR7bEqQKSkLipci/PqMXEHYHYAaxcRpXYoHWn6gLED/d8mrwvcBAF8Dguh0sXgJvnkQzNVIXvuFZ3h82R8zmSVZqDcOyLl+4bmZzXT9V2ZkOc70ujYqazmr+ef+rPKMjdDbkVqk84AAX7+ROtYE4lTF+p9/MZUFc0BNna0R7/ZKwuqYMIvKNvkwLJRqQOsfd3kMww7HCJuq3nIRVJHZ6VWzlNFE0HrOpvwdU3YZifJzKx27R+QXNETYkEN8APOybzwXjOBHZm4SqXAOBClqHuKHcBgkfojrcNrjjInGiOMEwet+ZT1gdQoMvgZh0kU3ikh3MCGPSf42orkChg/kmk+JhnhbTUGPuXwN+OWIYyeUwf5kV4liYynuAS+5OCIDCwZlMORD8p8SJzDiiFPKx/HPjwGucqbBN4/lpHsSJWpQqO9OYOPlIDQ2MtNBag5qoqFQbtuqJzC45i969Yxvl9W/jd94X2rdGsxf1fyypbDkU33yuqnFby6rhv43qCXozdh6pNGGoh4GOurqdhzEz8NUKVjqPR6pzDpeZq0E82mJ4UzJW5Tp9pd7Bmk1Rizo/k/1N62VmUrY4dlklH0U3sN43aOy96O5U88u9CEiGERd85LNrC9xHqOWkUtgxpRJKfpLXqtHhf8c+YVM0Dw8aEegOodV1gWSy252t9N3cUHUh5Ld2fHUMuNDEf4kKdnPfu0LopAyVIpCgm7SIo7ZB0FQ1COaqWMgOyslygkDvzAfMnSRzAyxisNj4L0laKqfUT4rC4tWN2sSBjG950BBh5LgNRgzE+jQyZeDQhFYcuqa2142Q04ovTGHWkpitLSbce/LNZzQFhNJig6JIqetCogjibtqOlK7x5caUa3AxEQZcdCVlMFOEN3tKfIP+3szBHhz auJoZFjn 7tPF00iC77LXF1+QuaiTgJivzz0M7CTp9i5EU05Dn+0vWkB/PK160SqtplICNRuJn4D81rMz+02PkbhWxIxhbsocPZID2Rh9VVNJUndYfLKr4bwUmBxh6NdYnPKSm8WXvTwbdiM0awKEOBuJW/5wMqjMrwmb8pbCO8O+wYP0qCpDOGqBJDoCr3/4jDmqdUPDL0iU7FlMHxjdY5m+SP7EFZ32Zvh/www7p4K8XpWXbDT4FITBwsm/WdbIYuN80H149uiOvWkq2HeKIyClXefYkOZ9Fm0+QfFCAfH4AAj+NV/tgaNKeTX9oukXfe4HlkPG3RUhd44Vc+6WwEDttjgORkizuhdqzeZcCUN3b2NVmtI7twkAWbV2wXyrz7Sc7XlOyRrMQDvF79CO5PbTI2EaT6r3wkLfK9vAk3Zb69Oha06I/wdM4CsDBEV7bQw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000239, 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, Feb 25, 2025 at 03:31:06PM +0000, Lorenzo Stoakes wrote: > On Tue, Feb 25, 2025 at 07:06:13AM -0800, Kees Cook wrote: > > > > > > 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.org wrote: > > >> > > From: Jeff Xu > > >> > > > > >> > > Provide support for CONFIG_MSEAL_SYSTEM_MAPPINGS on UML, covering > > >> > > the vdso. > > >> > > > > >> > > Testing passes on UML. > > >> > > > >> > Maybe expand on this by stating that it has been confirmed by Benjamin (I > > >> > _believe_) that UML has no need for problematic relocation so this is known to > > >> > be good. > > >> > > >> I may well be misreading this message, but this sounds to me that this > > >> is a misinterpretation. So, just to clarify in case that is needed. > > >> > > >> CONFIG_MSEAL_SYSTEM_MAPPINGS does work fine for the UML kernel. > > >> However, the UML kernel is a normal userspace application itself and > > >> for this application to run, the host kernel must have the feature > > >> disabled. > > >> > > >> So, UML supports the feature. But it still *cannot* run on a host > > >> machine that has the feature enabled. > > > > > >Sigh ok. Apologies if I misunderstood. > > > > > >Is there any point having this for the 'guest' system? I mean security wise are > > >we concerned about sealing of system mappings? > > > > UML guests are used for testing. For example, it's the default target for KUnit's scripts. Having sealing working in the guest seems generally useful to me. > > > > 'Having sealing working' you mean system sealing? Because mseal works fine > (presumably in UML, not tried myself!) Sorry, yes, I mean "system mapping msealing". > > System msealing lacks any test in this series (I did ask for them...), certainly > no kunit tests, so this seems a bit theoretical? Unless you're talking about the > theoretical interaction of kunit tests and VDSO sealing? Right, I meant theoretical interaction, but it would be useful for future KUnit tests of system mapping msealing too. > I mean can't we just introduce this at the time if we believe this'd be useful? Perhaps adding it as part of adding some KUnit tests that exercise the system mapping msealing would be the most sensible. > Generally I'm not a fan of adding features mid-way through a series, the > revisions are meant to be refinements of the original, not an evolving thing. > > So in general I'd prefer this to be added if + when we need it for something. Yup, makes sense. And it may be that KUnit tests need to exercise more than what UML can support, so even the KUnit idea may be invalid. Jeff, let's leave off UML for this initial "minimum viable feature" series, unless there is a strong reason to keep it. -- Kees Cook