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 4CE36C4332F for ; Tue, 31 Oct 2023 10:43:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C0B596B02C9; Tue, 31 Oct 2023 06:43:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B94776B02D2; Tue, 31 Oct 2023 06:43:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A36986B02D4; Tue, 31 Oct 2023 06:43:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 8FC1F6B02C9 for ; Tue, 31 Oct 2023 06:43:28 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 57DA4C0B29 for ; Tue, 31 Oct 2023 10:43:28 +0000 (UTC) X-FDA: 81405420096.11.B763649 Received: from bee.tesarici.cz (bee.tesarici.cz [77.93.223.253]) by imf21.hostedemail.com (Postfix) with ESMTP id 1A8F51C000D for ; Tue, 31 Oct 2023 10:43:25 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=tesarici.cz header.s=mail header.b=oa8JtXsd; spf=pass (imf21.hostedemail.com: domain of petr@tesarici.cz designates 77.93.223.253 as permitted sender) smtp.mailfrom=petr@tesarici.cz; dmarc=pass (policy=none) header.from=tesarici.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698749006; 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=XY7ucrKi2iTOdPWIkggmqP4KVp2cdCs0LWPX8GcUAxw=; b=HxehlIcgrl9F3gPdtNdDOkw/IijyVNhpdMMbyHFPM7vobJ9jP6oHG1gPJ08Y2C9lrmENnr MYaNDEgtJxtOev+OUvhKkai3ZbhxO8QHDritCP93Y6jNWNPCLMK+siDM2r/Y3QVN1Jad/c A9fF0s4rl4NQk/3TDp/6omjKSXNVWTc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698749006; a=rsa-sha256; cv=none; b=Ha3zrmmuoY0YKXVJbYCOuS2i/zVMG6RkJYb0/RlvO28FlXsC1UYY4E2wl7iOBa61FyJmr/ JqG1xU+mpVT3wtn8gRtO0yRT2KWML0Dszjxo5v8b9PZJ8Jkr4mmZTN5ssKAMnq+Np8JAbz 8GlPcpmU/2m/AB+gsr/2Xpq5dMNVNrw= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=tesarici.cz header.s=mail header.b=oa8JtXsd; spf=pass (imf21.hostedemail.com: domain of petr@tesarici.cz designates 77.93.223.253 as permitted sender) smtp.mailfrom=petr@tesarici.cz; dmarc=pass (policy=none) header.from=tesarici.cz Received: from meshulam.tesarici.cz (dynamic-2a00-1028-83b8-1e7a-4427-cc85-6706-c595.ipv6.o2.cz [IPv6:2a00:1028:83b8:1e7a:4427:cc85:6706:c595]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by bee.tesarici.cz (Postfix) with ESMTPSA id B244D190C97; Tue, 31 Oct 2023 11:43:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tesarici.cz; s=mail; t=1698749003; bh=jdCPy8MRdQgBRdIuWsT+HvlNGVFk2v04c88rT8qjyqw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=oa8JtXsdnPE4gwCftToiBbqkSMSYruxk7HFOzsgPFJUXN1KiQHmEZIDe7FYcTPyyi iPd2ruOehuiA3Az6MM9lOXB1GWJkpnQ+j9aKMyJwzCGi5Lp1RWh6FzOOvgz5LUYgoI SiZRztBziVKU/KKg1uSgtLTWa0nQPknt/a1qt9VqbPjT20dPJ1M+mnCdfHzPPLkhEk vekx+ktehleXu753zt6LKNMwyN88zJCOmjW9Gol2ANZToAEdT9pPeyHRynkr1CZ5Aa 9z7+uDLcktI5MFk85meR7Bjtx+7FZuq3Qu5ZRHLaC9DnjR8+ckQVEw/jMWRqaq6oDV TCBIzrCEp6BLA== Date: Tue, 31 Oct 2023 11:43:16 +0100 From: Petr =?UTF-8?B?VGVzYcWZw61r?= To: Rick Edgecombe Cc: x86@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, luto@kernel.org, peterz@infradead.org, kirill.shutemov@linux.intel.com, elena.reshetova@intel.com, isaku.yamahata@intel.com, seanjc@google.com, Michael Kelley , thomas.lendacky@amd.com, decui@microsoft.com, sathyanarayanan.kuppuswamy@linux.intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, Christoph Hellwig , Marek Szyprowski , Robin Murphy , iommu@lists.linux.dev Subject: Re: [PATCH 04/10] swiotlb: Use free_decrypted_pages() Message-ID: <20231031114316.0bfa8d91@meshulam.tesarici.cz> In-Reply-To: <20231017202505.340906-5-rick.p.edgecombe@intel.com> References: <20231017202505.340906-1-rick.p.edgecombe@intel.com> <20231017202505.340906-5-rick.p.edgecombe@intel.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1A8F51C000D X-Rspam-User: X-Stat-Signature: bsfgui9rcd5m7dzpot5m17aatzw5yzig X-Rspamd-Server: rspam03 X-HE-Tag: 1698749005-640290 X-HE-Meta: U2FsdGVkX1/uJpM/EeSrEikcXPIcXizWCaPFDiH2ZJ28bMHkB+q8wTTd/VdpP2XfX4aI+zDXQBx4nYcZCGE3K37/bmovof1k2pgb2fV92PzzZlWlZ3Yi73sG0Xr9gwuHdpl+xK4rCF/8blvMCxn9H6md7QCDgK2qefkdejLgr6qigg8WZfn2a1hKQUbWF5emIsC6pzZXokKQMN8BVX/yLeBzcl8f7icamhHesL7NIOdiVx2doVPY7w/E3x1OIvAmO5m4d5MAHcard4bf72URe5GVUicJMFaW44nlkEVXCn2So3MpNaUescHXXd/V5d8sntuDPO/B+om03QsdcM5KR6rpojbjJCt4VXYNOHS2NBJd3JrRUq21/qJe794YyTKZ1MMeQX60oLoDZOPUKAeLErtcVnMypEqIV1Jwz05HgAWq5CNQTYyjbNvjyWdPFZ+U3jm3mVy+qQ0xotmUb6Ct0KKaaHLktcpLyHdTMyuaV6vqY2+VYUik0r5y7vABA0IBqh4n+IHknu3pchU7QCcRwikGIb1G1nh0MouX4fOs7oHq5zXoAwoLoBtsV+EH9dOLrHzTgCf7HWzphjtooCBkIvor/bhZHebyE9ge724KSL1PJ9cw2OutFy6h4n6kqgkxfXDKXUqtM+FwbPZs+Qm+Br21vF5fD0N5s6k0i8sgTYkY3a/19NI4MVdKYFADrd1ALB5APupTpO5ndt3lU+HeQozd08+beo5YdQF+zqOSimagrkeASir4lsAAAhSvMj6qilLx95YnZL5PZ3dcmW09KGF0YXwlQwFEQeNlmFVI+ZMp/DZrh4VDgtVbrpUZGD3GSf81ESEP4FJ6dbLitP8QCji8BF4x2pSXo5Be1Ym6x01DTDwZz6nN/R8KOM9CmdNvrLQrSnvjl2uWt59SlZOHzCiwgpToOFAeTf0mHoV0vDSlVEkxhhwDjyxvSQCImkCqo+vsJQYzIspOtMR67ap CxDkMms8 BiiYWW3vA5Eix5cIVWgoX7SlvUWCnD0/K0LqeqcBQi9+JdCr7tsjOja+fpwm2beMCzWFs4rn2aJ5Yub7BdfMdiWmrW59TbMMJwbF0dezWL1MBoYWGyELY/SMVM4hG7VXxtfPaMWF3dlq7N9ez74K8VsLN64Lr+2y4xnhvi+5Ui9fmvcftYfEaaLm/ilPGuZetmnqvZFgDlbH0fu3oHSwp0S57AxdG7LXzVdxOlW8rY5EVZWr7plaD3PTW3zoayc6Laee1emdWT6YSe47iW0tbqapJp/aKok5mzbtuTgug5t4SPu9KEXHwwgm/KQp4ZqxSMHR5qZ/hx50n1iun0gum7jrVH8xPvtalGoIulZDlpqRKeGrcf3GW8wS621+1ihx+3hkf34smkYEFfHqyHsRyvzckYzoXovMy1z6MxEfxny39r80D9fMrMKZ3kzXCbmIz18G6EgWw34pizsKVFacaHK9FzuD+QbUMhjRBryL4OC5rRkC3r9od+oYjyooHj2fqt+fiyVTPq0fPFbkk9h0eztWMqjHB0Mhl0JCE X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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, 17 Oct 2023 13:24:59 -0700 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. > > Swiotlb could free decrypted/shared pages if set_memory_decrypted() fails. > Use the recently added free_decrypted_pages() to avoid this. > > In swiotlb_exit(), check for set_memory_encrypted() errors manually, > because the pages are not nessarily going to the page allocator. > > Cc: Christoph Hellwig > Cc: Marek Szyprowski > Cc: Robin Murphy > Cc: iommu@lists.linux.dev > Signed-off-by: Rick Edgecombe > --- > kernel/dma/swiotlb.c | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c > index 394494a6b1f3..ad06786c4f98 100644 > --- a/kernel/dma/swiotlb.c > +++ b/kernel/dma/swiotlb.c > @@ -524,6 +524,7 @@ void __init swiotlb_exit(void) > unsigned long tbl_vaddr; > size_t tbl_size, slots_size; > unsigned int area_order; > + int ret; > > if (swiotlb_force_bounce) > return; > @@ -536,17 +537,19 @@ void __init swiotlb_exit(void) > tbl_size = PAGE_ALIGN(mem->end - mem->start); > slots_size = PAGE_ALIGN(array_size(sizeof(*mem->slots), mem->nslabs)); > > - set_memory_encrypted(tbl_vaddr, tbl_size >> PAGE_SHIFT); > + ret = set_memory_encrypted(tbl_vaddr, tbl_size >> PAGE_SHIFT); > if (mem->late_alloc) { > area_order = get_order(array_size(sizeof(*mem->areas), > mem->nareas)); > free_pages((unsigned long)mem->areas, area_order); > - free_pages(tbl_vaddr, get_order(tbl_size)); > + if (!ret) > + free_pages(tbl_vaddr, get_order(tbl_size)); > free_pages((unsigned long)mem->slots, get_order(slots_size)); > } else { > memblock_free_late(__pa(mem->areas), > array_size(sizeof(*mem->areas), mem->nareas)); > - memblock_free_late(mem->start, tbl_size); > + if (!ret) > + memblock_free_late(mem->start, tbl_size); > memblock_free_late(__pa(mem->slots), slots_size); > } > > @@ -581,7 +584,7 @@ static struct page *alloc_dma_pages(gfp_t gfp, size_t bytes) > return page; > > error: > - __free_pages(page, order); > + free_decrypted_pages((unsigned long)vaddr, order); > return NULL; > } I admit I'm not familiar with the encryption/decryption API, but if a __free_pages() is not sufficient here, then it is quite confusing. The error label is reached only if set_memory_decrypted() returns non-zero. My naive expectation is that the memory is *not* decrypted in that case and does not require special treatment. Is this assumption wrong? OTOH I believe there is a bug in the logic. The subsequent __free_pages() in swiotlb_alloc_tlb() would have to be changed to a free_decrypted_pages(). However, I'm proposing a different approach to address the latter issue here: https://lore.kernel.org/linux-iommu/20231026095123.222-1-petrtesarik@huaweicloud.com/T/ Petr T