From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 52CDE3FE658 for ; Thu, 30 Apr 2026 08:45:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777538751; cv=none; b=tiRYz0Rfw1ygCCfazHMxZvnrJnoNE0YGwIxq7+WoGGEjP29CTjP1ce5zSCMfENtcviHSQLPdXTQ2QcUK7u0pkVT9saNLQwjZL2zZy5V0xu9S9ON4+OzRkwapVvuPd3LnIlT3lMHOOj7EaZe4xG6gFtbcfZQSwKAw+3Xym2h9SiM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777538751; c=relaxed/simple; bh=+MBhZkziafGe9boIFxf7Lv1bigAUU/KzlTMIHJ2Vi3I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MFNKzx2cwHbo7M183VEgfBRV41K0f9ZSUnAWjgLsFfZfpQPsYOTZZEyV50zmrL94VW+kn+DQGxgLGwFvM+CNOV3gC9frjUjZBjML5+ZaCgHYy1K/2/cy9bfivm7r8LpyfhZFjkcJ05CwH0HYeIgz6QJ7KZyA7eYy60H1J+YSizM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=vFDt5+4O; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="vFDt5+4O" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2ABDBC2BCB3; Thu, 30 Apr 2026 08:45:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1777538750; bh=+MBhZkziafGe9boIFxf7Lv1bigAUU/KzlTMIHJ2Vi3I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=vFDt5+4ORGzFWPnYEcamCPOAZJQoO/abaBIsk6lC6+NMTXdB2QMEX9ypUPp7QmWJs rNI2Ys0BxlLYbFkYEqs9b1ohRRPwwq2I11hLwqPf0utvNtgT2myhvd7Bez+uIHB253 BwLURQ6V71f5oT4bq22zqYjcP1b3EwS+SgGaFoJbQCrJgTcS9xkFaR8NoVfo92NLv1 o7IJmrXvhcPwqszl2lX1aKwZ3TUH8lurZy/ALEg6rJoErpIyq5jG9Fht0xH//QFXV8 G+WKqJ/LSqVptJu56t1X1TEvFk8jgGrE4iQhFv1op00lqDs2BgqtVrQ/qlb5MWUQQG zho0BCGT4MaaA== Date: Thu, 30 Apr 2026 10:45:43 +0200 From: Mike Rapoport To: Catalin Marinas Cc: Kameron Carr , will@kernel.org, suzuki.poulose@arm.com, steven.price@arm.com, ryan.roberts@arm.com, dev.jain@arm.com, yang@os.amperecomputing.com, shijie@os.amperecomputing.com, kevin.brodsky@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] arm64: mm: support set_memory_encrypted/decrypted for vmalloc addresses Message-ID: References: <20260406213317.216171-1-kameroncarr@linux.microsoft.com> <001301dcc932$21cb6d80$65624880$@linux.microsoft.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Hi Catalin, On Tue, Apr 14, 2026 at 05:46:06PM +0100, Catalin Marinas wrote: > On Fri, Apr 10, 2026 at 02:36:42PM -0700, Kameron Carr wrote: > > On Friday, April 10, 2026 4:06 AM, Catalin Marinas wrote: > > > Could you give more details about the user of set_memory_decrypted() on > > > vmalloc()'ed addresses? I think this came up in the past and I wondered > > > whether something like GFP_DECRYPTED would be simpler to implement (even > > > posted a hack but without vmalloc() support). If it is known upfront > > > that the memory will be decrypted, it's easier/cheaper to do this on the > > > page allocation time to change the linear map and just use > > > pgprot_decrypted() for vmap(). No need to rewrite the page table after > > > mapping the pages. > [...] > > In this use case, whether to decrypt the memory can always be known at > > time of allocation, so a solution like GFP_DECRYPTED is an option. > > > > I think I found the hack you mentioned > > (https://lore.kernel.org/linux-arm-kernel/ZmNJdSxSz-sYpVgI@arm.com/). The > > feedback in Michael Kelley's reply covers the key considerations well. > > Yes, that's the thread. It started originally as a GICv3 need > (eventually we went for genpool). > > > He likely had netvsc's use of vmalloc in mind when he made the point > > "GFP_DECRYPTED should work for the three memory allocation interfaces and > > their variants: alloc_pages(), kmalloc(), and vmalloc()." His other > > points already cover the concerns I had in mind around handling errors > > from set_memory_decrypted()/encrypted(), etc. > > > > What is the current status of your proposed GFP_DECRYPTED implementation? > > Is this something you are actively working on? > > Not really. But I've been looking at it again and I think it adds more > problems than it solves. A GFP flag would be passed down to > kmem_cache_alloc() and confuse the slab management if some pages are > encrypted, others not for the same kmem_cache (SLAB_NO_MERGE wouldn't > help). I wonder whether something like SLAB_DECRYPTED would work better > for this if we really need it (not aware of any user though). > > Anyway, let's ignore slab for now and look at vmalloc(). I can see > hv_ringbuffer_init() using an explicit vmap(pgprot_decrypted()). While > you could do this, it might be better to just add a VM_DECRYPTED flag > and a few wrappers like vmalloc_decrypted(). It would call > set_memory_decrypted() for the allocated pages and use > pgprot_decrypted() for vmap. On vfree(), it will have to set the pages > back to encrypted. It should be fairly mechanical to do (or a 5 min job > for an LLM ;)). A GFP + SLAB flag is semantically better than only implementing decrypted allocations only in vmalloc, but it's surely way more complex and intrusive and we are running low on gfp flags on 32 bits :) But I think we can push the _decrypted to kvmalloc() that would do either kmalloc() + set_memory_decrypted() or vmalloc_decrypted() and it seems that x86 and drivers could use that instead of alloc_pages() + set_memory_decrypted(). We also would want also to make x86::set_memory_decrypted() to only accept linear^w direct map addresses to ensure consistency between architectures. > -- > Catalin > -- Sincerely yours, Mike.