From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2C9B125776 for ; Fri, 12 Jun 2026 18:18:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.217.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781288291; cv=none; b=lDO9mz9ZBAs50Vjz/Vjz+c4KGlxM+hwcj8/0v7eOoWusjPtMtASaIw47m55YPK0S1ZLRUPF58QC7xnd7B5VRtdU/ab3wU5IgZNHeUAiFshyRaCT71mDsrs3rFEYLPyfLHVpkUhN/KVXNE+nt44Ng9CY8bTIBB+GcqKwSuu3f3Z4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781288291; c=relaxed/simple; bh=OU0Mhx3ElwBHVBhJupwFS5bT4WtEfl13JomknDaA7lM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TgC6huwQiRMKw6yz/t1ht8yO3DD/UayZ/4QilDSYSvAGcGgPtNBzp6u8rguaVH3aezVwcOhOwwdxdtCCjXEfqmob8DAwqAHTMi6mBuIHlOLPf2YOVHh33m00+rYI4mMXB3JXDOnt7TIVwsJGdyP+btc8HDJ8pSVDtHnaqzKzhOQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca; spf=pass smtp.mailfrom=ziepe.ca; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b=XDrdmn0q; arc=none smtp.client-ip=209.85.217.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ziepe.ca Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ziepe.ca header.i=@ziepe.ca header.b="XDrdmn0q" Received: by mail-vs1-f54.google.com with SMTP id ada2fe7eead31-6cb414a5d50so960104137.3 for ; Fri, 12 Jun 2026 11:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; t=1781288289; x=1781893089; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=+iqIpA7z+5uzNHU9YvroEcwha8urHL7cOeSZxwXaBPs=; b=XDrdmn0qHjio7TNkPYanlRTXJbLBiGaoLX12xpepcKC4KB9eWHE+UF2fnp23Ng/6qT XJMAM3TxSgIJI6Yuo2gbXaBYQ+vysfXe3GWvh43AV7z3IoN01AusT68oUW/cjBnE0ClC doa67nyUh8vBEG8HfhaO7cJqaekb/UWp/pfR6HtLwJKRItg4Llxvdnkm7oe7lQkuMoBb EKNAPvee3d5NYet8qP0KZeY5hZZNftA6YBJDlrzbU+FbYeuSSG6Sx5YvhdUTGpyQPzRR 4Mq6A8twkxiaqlVOHwC1/Fm+XMGPv0aYkQi2cpeTwT5kzgCCVrtKCk9iGSpihH5RtO0i syIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1781288289; x=1781893089; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=+iqIpA7z+5uzNHU9YvroEcwha8urHL7cOeSZxwXaBPs=; b=THrur1i2xZT+PCzWCgCAeldOt4XcxmUPb2qMGnxEe8G94PTVkuKG4rJ2+v+xyXLw2b zlsXUztZpRg+L3QXYWtgsjA+6CvM+/awLTyANcc3wW5ZAixz2fmn06szOTSBwO3E7rUg wgCTFANr2vAds+1hPNyscLOk4BzXvKxihmDQyyqxFRKx7euIgbKEEZNYZCRyAmUstaIi ZT7pW5CsFGGOi1e6FCpRQFmSu4yNyAA92H5VPApU9Y+BEW0xv9A997qgx5Dr5n01Svic 4He+akXTHktxNoXyDwNhVuBEMl3qVyKWWAPLAiQMAC4nX90+DewJVhgJIfNrkXmgPMIG VYkg== X-Forwarded-Encrypted: i=1; AFNElJ8l/OSSQKWAZhYMpQHUsvEaoyyXcaxxnDtPDzjmeEjDExR7N8Nzo4htfROS0cAUGMAyReFZm9bKhIQcisc=@vger.kernel.org X-Gm-Message-State: AOJu0YwFWVvzkXIhCE7a5S8AilNAywcxcWZWqhpKSA9PFAd1ol0hvy+c nBFh3IIQUHQcscnUDQJrcMc2DKsk3HprKIH9gQfYNjA6Posya48/+Rysi1OkYs4sC2Q= X-Gm-Gg: Acq92OGM0Xo9tzmSMJuljX5ICgzcdzk9y6y8jv3CNjvKrzn5qBIyOK1yZy5NXkA0/I0 ByvdslzCy9/qVbCBB4TnJPCSCbUsuVa22XG3pmhwHsvh/kfdhT9IO8LSvNh3EJpoZmuFa7lLgg6 F+SiUsz0Aw5mIbaxcvfq7xcnAk1Gg7zqDazYTYvk+NOg653HDaZqv02vUXYGHTHlrn9+U+eBjWm HjO9u9gYZXUeGlhopffYK275PlXPZjHdkwMvnZLaekY83qmwNdSTV+Bn4Eecnn4jtkHvbeFWQn2 Dbik9SVciPCP5qjxiKvIds+Qpcm5S0aJs646LuiseauVsb+mJV+63Jejc6ZIhWVUxwuj23/NHR2 w6ph2t3gDAMVreHiBYavSRyWF/d42s45X8URF7M3DQlPe/xEY1wtz6t12JMX0d6gIiF7ynQtvyX JJOGZoOtHAYgqr/FXJXUO2nYdYU5svg6zc5zm3IFbaGRDWfaGfxuA1mDlxia84JuIBpnsnTD3Eb RbEtg== X-Received: by 2002:a05:6102:5a99:b0:6d5:91f0:21b4 with SMTP id ada2fe7eead31-71e88e0e755mr3085010137.29.1781288289001; Fri, 12 Jun 2026 11:18:09 -0700 (PDT) Received: from ziepe.ca (crbknf0213w-47-54-130-67.pppoe-dynamic.high-speed.nl.bellaliant.net. [47.54.130.67]) by smtp.gmail.com with ESMTPSA id af79cd13be357-91619f3c324sm282729185a.21.2026.06.12.11.18.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 12 Jun 2026 11:18:08 -0700 (PDT) Received: from jgg by wakko with local (Exim 4.97) (envelope-from ) id 1wY6SF-00000008EqU-36LA; Fri, 12 Jun 2026 15:18:07 -0300 Date: Fri, 12 Jun 2026 15:18:07 -0300 From: Jason Gunthorpe To: Catalin Marinas , Christoph Hellwig Cc: Kameron Carr , akpm@linux-foundation.org, urezki@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, rppt@kernel.org, mhklinux@outlook.com, linux-coco@lists.linux.dev, Suzuki K Poulose Subject: Re: [RFC PATCH] mm/vmalloc: add vmalloc_decrypted() and vzalloc_decrypted() Message-ID: <20260612181807.GP1066031@ziepe.ca> References: <20260521205834.1012925-1-kameroncarr@linux.microsoft.com> <20260611114954.GC1066031@ziepe.ca> 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: On Fri, Jun 12, 2026 at 06:49:28PM +0100, Catalin Marinas wrote: > On Thu, Jun 11, 2026 at 08:49:54AM -0300, Jason Gunthorpe wrote: > > On Mon, Jun 08, 2026 at 04:37:02PM +0100, Catalin Marinas wrote: > > > > +/** > > > > + * vzalloc_decrypted - allocate zeroed virtually contiguous decrypted memory > > > > + * @size: allocation size > > > > + * > > > > + * Like vmalloc_decrypted(), but the memory is set to zero. > > > > + * > > > > + * Return: pointer to the allocated memory or %NULL on error > > > > + */ > > > > +void *vzalloc_decrypted_noprof(unsigned long size) > > > > +{ > > > > + void *addr; > > > > + > > > > + addr = __vmalloc_node_range_noprof(size, 1, VMALLOC_START, VMALLOC_END, > > > > + GFP_KERNEL, > > > > + pgprot_decrypted(PAGE_KERNEL), > > > > + VM_DECRYPTED, NUMA_NO_NODE, > > > > + __builtin_return_address(0)); > > > > + if (addr) > > > > + memset(addr, 0, size); > > > > > > Talking to Suzuki, the small window between set_memory_decrypted() and > > > memset() potentially exposing stale data is safe, at least for Arm CCA > > > as the memory would be scrubbed (there are other places in the kernel > > > where we do something similar). I assume that's also the case for other > > > architectures, although not sure what pKVM does. > > > > It seems like a poor practice though, this should probably be > > re-organized to use __GFP_ZERO so things are ordered sensibly. > > __GFP_ZERO doesn't work if the intermediate set_memory_decrypted() > mangles the data (e.g. changes encryption keys) and it no longer reads > as zeros. I thought arches are either preserving the memory content or zeroing it, you are saying some arch leaves it as garbage? I'd argue that's an arch bug and they should clear it in their path. Otherwise this sharp edge is not documented and we have many other places getting it wrong, eg system_heap_allocate() doesn't re-zero the memory after decrypting it. > > But what is the purpose of this? I guess some hyperv thing - but > > shouldn't we have a more structured way to "DMA map" things for the > > hypervisor instead of stuff like this? Why can't you use > > dma_alloc_coherent() which actually gives you an address that is > > sensible to pass to the hypervisor? > > IIRC netvsc_init_buf() uses vzalloc() to allocate some memory and that > buffer ends up in set_memory_decrypted() via vmbus_establish_gpadl(). > arm64 does not support changing the decrypted/shared attributed of > vmalloc mappings and I don't think we should add it. Better to just > allocate it properly upfront. Sure > We might be able to use the DMA API but we won't get something like > vmalloc() - physically non-contiguous. The entry point is dma_alloc_noncontiguous() and you get a scatterlist back. > I think dma_alloc_noncontiguous() just falls back to > dma_direct_alloc_pages() in the absence of an iommu. In all cases you get a scatterlist with a CPU list and a DMA list. iommu gives a smaller DMA list. If you want a vmap then you can feed that CPU page list from the sgl into vmap(). A dma_alloc_noncontiguous_vmap() helper would not be hard to make, and IMHO, would make alot more sense for hyperv to treat the memory access from the hypervisor as "DMA" instead of trying to re-invent the DMA API.. :\ HCH was already saying we should not be allowing drivers to use set_memory_decrypted() at all, and hyperv is the biggest non-core user right now... Jason