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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A5A99C197BF for ; Thu, 27 Feb 2025 21:23:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=P4EHyml6sgsrseMBGiXLmuhmECRf034wo9gePu93sHg=; b=t/OSo2Jk4T7ft7wElS4JFFyG02 9KTqvLEeyI/i8Qdb18/flAc2x/ICcL0i+1z16h4w82aFm/0B4J98VQyyum+DvAYRyLtuzbQ8Yp2m8 wR+kYHTaI100HTVFAaokyOzz6GGh1Yr6eylG5oKMQkFJVMNt8IWTXJHWrM6kG3fzUtvviT60MfQ7V FoeZl70ABfncxYPjqz6uyhZtszn/GDV5hGtquMvMkgPblYzQyuaG0g9SgrhGzEyzLzBVJg1DkyLyv Dc18KN+LXCUrSxwQyhpft8yMi7ZY/FBFowIGTmc6I031Kq1DZy4Z1RRInrDjHsG+hMKmJ5q678yxI Q+Gp43fw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tnlLK-00000008shW-36IG; Thu, 27 Feb 2025 21:22:54 +0000 Received: from tor.source.kernel.org ([2600:3c04::f03c:95ff:fe5e:7468]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tnlJm-00000008sa8-1F7E for linux-arm-kernel@lists.infradead.org; Thu, 27 Feb 2025 21:21:18 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 28F4B61136; Thu, 27 Feb 2025 21:21:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE34DC4CEDD; Thu, 27 Feb 2025 21:21:13 +0000 (UTC) Date: Thu, 27 Feb 2025 21:21:11 +0000 From: Catalin Marinas To: Will Deacon Cc: Steven Price , "Aneesh Kumar K . V" , Suzuki K Poulose , Marc Zyngier , James Morse , Oliver Upton , Zenghui Yu , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Joey Gouly , Alexandru Elisei , Christoffer Dall , Fuad Tabba , linux-coco@lists.linux.dev, Ganapatrao Kulkarni , Gavin Shan , Shanker Donthineni , Alper Gun , kvmarm@lists.linux.dev, kvm@vger.kernel.org Subject: Re: [PATCH v7 09/11] arm64: Enable memory encrypt for Realms Message-ID: References: <20241017131434.40935-1-steven.price@arm.com> <20241017131434.40935-10-steven.price@arm.com> <5aeb6f47-12be-40d5-be6f-847bb8ddc605@arm.com> <20250227002330.GA24899@willie-the-truck> <20250227172254.GB25617@willie-the-truck> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250227172254.GB25617@willie-the-truck> X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Feb 27, 2025 at 05:22:55PM +0000, Will Deacon wrote: > On Thu, Feb 27, 2025 at 10:55:00AM +0000, Catalin Marinas wrote: > > On Thu, Feb 27, 2025 at 12:23:31AM +0000, Will Deacon wrote: > > > On Wed, Feb 26, 2025 at 07:03:01PM +0000, Catalin Marinas wrote: > > > > On Wed, Feb 19, 2025 at 02:30:28PM +0000, Steven Price wrote: > > > > > > @@ -23,14 +25,16 @@ bool rodata_full __ro_after_init = IS_ENABLED(CONFIG_RODATA_FULL_DEFAULT_ENABLED > > > > > > bool can_set_direct_map(void) > > > > > > { > > > > > > /* > > > > > > - * rodata_full and DEBUG_PAGEALLOC require linear map to be > > > > > > - * mapped at page granularity, so that it is possible to > > > > > > + * rodata_full, DEBUG_PAGEALLOC and a Realm guest all require linear > > > > > > + * map to be mapped at page granularity, so that it is possible to > > > > > > * protect/unprotect single pages. > > > > > > * > > > > > > * KFENCE pool requires page-granular mapping if initialized late. > > > > > > + * > > > > > > + * Realms need to make pages shared/protected at page granularity. > > > > > > */ > > > > > > return rodata_full || debug_pagealloc_enabled() || > > > > > > - arm64_kfence_can_set_direct_map(); > > > > > > + arm64_kfence_can_set_direct_map() || is_realm_world(); > > > > > > } > > > > > > > > > > Aneesh pointed out that this call to is_realm_world() is now too early > > > > > since the decision to delay the RSI detection. The upshot is that a > > > > > realm guest which doesn't have page granularity forced for other reasons > > > > > will fail to share pages with the host. > > > > > > > > > > At the moment I can think of a couple of options: > > > > > > > > > > (1) Make rodata_full a requirement for realm guests. > > > > > CONFIG_RODATA_FULL_DEFAULT_ENABLED is already "default y" so this > > > > > isn't a big ask. > > > > > > > > > > (2) Revisit the idea of detecting when running as a realm guest early. > > > > > This has the advantage of also "fixing" earlycon (no need to > > > > > manually specify the shared-alias of an unprotected UART). > > > > > > > > > > I'm currently leaning towards (1) because it's the default anyway. But > > > > > if we're going to need to fix earlycon (or indeed find other similar > > > > > issues) then (2) would obviously make sense. > > > > > > > > I'd go with (1) since the end result is the same even if we implemented > > > > (2) - i.e. we still avoid block mappings in realms. > > > > > > Is it, though? The config option is about the default behaviour but there's > > > still an "rodata=" option on the command-line. > > > > Yeah, that's why I suggested the pr_err() to only state that it cannot > > set the direct map and consider rodata=full rather than a config option. > > We already force CONFIG_STRICT_KERNEL_RWX. > > rodata=full has absolutely nothing to do with realms, though. I fully agree, that's what I said a couple of emails earlier (towards the end, not quoted above). > It just > happens to result in the linear map being created at page granularity > and I don't think we should expose that implementation detail like this. I wasn't keen on adding a new realms=on or whatever command line option, so I suggested the lazy but confusing rodata=full. > > But we can also revisit the decision not to probe the RSI early. > > Alternatively, could we predicate realm support on BBM level-3 w/o TLB > conflicts? Then we could crack the blocks in the linear map. Long term, I agree that's a better option. It needs wiring up though, with some care to handle page table allocation failures at run-time. I think most callers already handle the return code from set_memory_*(). -- Catalin