From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B372F1BDFE for ; Mon, 23 Oct 2023 17:23:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=none Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 6DEDE2F4; Mon, 23 Oct 2023 10:23:43 -0700 (PDT) Received: from [10.57.5.125] (unknown [10.57.5.125]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 19BFE3F762; Mon, 23 Oct 2023 10:22:58 -0700 (PDT) Message-ID: <289f5f83-adc7-4077-b4c0-c951484dd092@arm.com> Date: Mon, 23 Oct 2023 18:22:57 +0100 Precedence: bulk X-Mailing-List: iommu@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 06/10] dma: Use free_decrypted_pages() Content-Language: en-GB To: "Edgecombe, Rick P" , "Lutomirski, Andy" , "linux-mm@kvack.org" , "dave.hansen@linux.intel.com" , "thomas.lendacky@amd.com" , "Reshetova, Elena" , "kirill.shutemov@linux.intel.com" , "mingo@redhat.com" , "Christopherson,, Sean" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "Yamahata, Isaku" , "Cui, Dexuan" , "mikelley@microsoft.com" , "hpa@zytor.com" , "peterz@infradead.org" , "bp@alien8.de" , "linux-s390@vger.kernel.org" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "x86@kernel.org" Cc: "hch@lst.de" , "m.szyprowski@samsung.com" , "iommu@lists.linux.dev" References: <20231017202505.340906-1-rick.p.edgecombe@intel.com> <20231017202505.340906-7-rick.p.edgecombe@intel.com> From: Robin Murphy In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2023-10-23 17:46, Edgecombe, Rick P wrote: > On Wed, 2023-10-18 at 18:42 +0100, Robin Murphy wrote: >> On 2023-10-17 21:25, Rick Edgecombe wrote: >>> On TDX it is possible for the untrusted host to cause >>> set_memory_encrypted() or set_memory_decrypted() to fail such that >>> an >>> error is returned and the resulting memory is shared. Callers need >>> to take >>> care to handle these errors to avoid returning decrypted (shared) >>> memory to >>> the page allocator, which could lead to functional or security >>> issues. >>> >>> DMA could free decrypted/shared pages if set_memory_decrypted() >>> fails. >>> Use the recently added free_decrypted_pages() to avoid this. >>> >>> Several paths also result in proper encrypted pages being freed >>> through >>> the same freeing function. Rely on free_decrypted_pages() to not >>> leak the >>> memory in these cases. >> >> If something's needed in the fallback path here, what about the >> cma_release() paths? > > You mean inside cma_release(). If so, unfortunately I think it won't > fit great because there are callers that are never dealing with shared > memory (huge tlb). The reset-to-private operation does extra work that > would be nice to avoid when possible. > > The cases I thought exhibited the issue were the two calls sites of > dma_set_decrypted(). Playing around with it, I was thinking it might be > easier to just fix those to open code leaking the pages on > dma_set_decrypted() error. In which case it won't have the re-encrypt > problem. > > It make's it less fool proof, but more efficient. And > free_decrypted_pages() doesn't fit great anyway, as pointed out by > Christoph. My point is that in dma_direct_alloc(), we get some memory either straight from the page allocator *or* from a CMA area, then call set_memory_decrypted() on it. If the problem is that set_memory_decrypted() can fail and require cleanup, then logically if that cleanup is necessary for the dma_free_contiguous()->__free_pages() call, then surely it must also be necessary for the dma_free_contiguous()->cma_release()->free_contig_range()->__free_page() calls. Thanks, Robin.