From nobody Wed Apr 1 09:43:48 2026 Received: from mail-wm1-f73.google.com (mail-wm1-f73.google.com [209.85.128.73]) (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 CA542327C18 for ; Mon, 30 Mar 2026 14:51:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774882287; cv=none; b=OQwKFvTVmbvtkz99ypo80XzHrrC7dMR9gmByZUyXMRPdt/PbXGKguPCyGkYyJHl+yp0naPltolx80SGeoVRoWMQhWFzAruczM1u4GAz3JJRs5vDRkhY0r1mC+JcG8fZQSep4EWkqwidE/AsSjmrb5UXaRYwlEvsE6NuBgNbBENU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774882287; c=relaxed/simple; bh=FXMPltbZcZ5fueDOME6tu6lHCg7hLrz8WRDK2s/pB8o=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=NvLsOH6DunMPnzvUzVZLF6XYBFO84GDejYZJz7NOZc8iGh6FEH1/UiQ5pR1hAUNCH8vGhpwaYn7HacSzRPciQxkkojl8oXZmTUc4xers75WDs+7ju9xRx/PQax8XJWog8u1Wnr3p9yOQdubfoKExv2W4WhCHDrlqcuA/w2kKc9Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--smostafa.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=FI5MJTWP; arc=none smtp.client-ip=209.85.128.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--smostafa.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="FI5MJTWP" Received: by mail-wm1-f73.google.com with SMTP id 5b1f17b1804b1-48542d5aa9eso41527305e9.0 for ; Mon, 30 Mar 2026 07:51:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774882284; x=1775487084; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=J65BpbTDZfVi4pM0t9Ln1+SAYufEj40Do3q1lK1k0LY=; b=FI5MJTWPRFJ6yZws+SUsOTVYt27wYF5WWAHFMD9xyz2IiWV/Y4AIamUEVHw34vwB5o b7AdsMPr9nGC3JPbINtklHB+mpIbRDipUSU7qOexSZBhgzHOORtlHCaqWNsBxekLaE+j uLHyqQPacc1yUfArjB3Ky8OorYf5N46SuG1dMBJNyzDaGcO40/QKfMGuBUjNZywIKwVD u0lGVsgr3NNqtrdYg+I/Wp6ExidgsY4nWuXJmWqgsuIPRdmLo3aopwJtVrb0o1DSW/tZ Vb1K05vGmPrni5W4wm3oBWPnif2f4mzlKZ1oddw4v3dwok8Z/DXq/xsWtHKUPxIvi7KN AEzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774882284; x=1775487084; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=J65BpbTDZfVi4pM0t9Ln1+SAYufEj40Do3q1lK1k0LY=; b=Z5YqnUajkRJgW5muFkGZc5UPK13Df2+GaDbAdueWK/gJ/i0lIYCUFF4JH2c76Rp0YY SFA2g9VpQCuNkE8qjg6Ug5/0ASeAQ6Z1OB7a6NL/pNL/b2BONFBsssb4dzNheIpRg58Y UvK+7JJ6cxN+z1Ngbcylj1rfWTxhDWa4/dwE81YVNKtvD7ZPE9pavyUhtF3hAW/LwhGm DtBXr4lIkpIYhx3Ahn7+inu2Cg+LCmq32ioTxtr+j2bSsHhJojKTB3Ah/ZI8VtIVuwe7 yCxw7dvfxT/T2pMT2nRmUZTjurtA6aX6TJclUnMNzeBTFeqtxINEvxXnHy+zjXxub0z0 JikQ== X-Forwarded-Encrypted: i=1; AJvYcCVU82bIJrLTmfHRI851mgqxM35/bU1T25mj2LAuhwd7KZYyyevcoAAtIpKFhexNqybFwEv3BAn9OThtVvc=@vger.kernel.org X-Gm-Message-State: AOJu0Yy6YHR2CtXGua3idjSWWcXMEN/OiWAGEJUIUr3m4uBX+Y6/C34t DiV2DdUR7P5GSUOi+6aIFO+ywAIBnpaLuT5tX6Nl/uAJ5NR+pD+mqJ5O01H+vOI5fu7ESX3lKnC drzeXTLA23NkynQ== X-Received: from wmpd21.prod.google.com ([2002:a05:600c:4c15:b0:485:3890:399c]) (user=smostafa job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:1d1e:b0:486:fe46:b647 with SMTP id 5b1f17b1804b1-48727f00d8fmr210293035e9.10.1774882283962; Mon, 30 Mar 2026 07:51:23 -0700 (PDT) Date: Mon, 30 Mar 2026 14:50:39 +0000 In-Reply-To: <20260330145043.1586623-1-smostafa@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260330145043.1586623-1-smostafa@google.com> X-Mailer: git-send-email 2.53.0.1185.g05d4b7b318-goog Message-ID: <20260330145043.1586623-2-smostafa@google.com> Subject: [RFC PATCH v2 1/5] dma-mapping: Avoid double decrypting with DMA_RESTRICTED_POOL From: Mostafa Saleh To: iommu@lists.linux.dev, linux-kernel@vger.kernel.org Cc: robin.murphy@arm.com, m.szyprowski@samsung.com, will@kernel.org, maz@kernel.org, suzuki.poulose@arm.com, catalin.marinas@arm.com, jiri@resnulli.us, jgg@ziepe.ca, aneesh.kumar@kernel.org, Mostafa Saleh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" In case a device have a restricted DMA pool, it will be decrypted by default. However, in the path of dma_direct_alloc() memory can be allocated from this pool using, __dma_direct_alloc_pages() =3D> dma_direct_alloc_swiotlb() After that from the same function, it will attempt to decrypt it using dma_set_decrypted() if force_dma_unencrypted(). Which results in the memory being decrypted twice. It's not clear how the does realm world/hypervisors deal with that, for example: - CCA: Clear a bit in the page table and call realm IPA_STATE_SET. - TDX: Issue a hypercall. - pKVM: Which doesn't implement force_dma_unencrypted() at the moment, uses a share hypercall. Change that to only encrypt/decrypt memory that are not allocated from the restricted dma pools. Fixes: f4111e39a52a ("swiotlb: Add restricted DMA alloc/free support") Signed-off-by: Mostafa Saleh --- kernel/dma/direct.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 8f43a930716d..27d804f0473f 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -79,7 +79,7 @@ bool dma_coherent_ok(struct device *dev, phys_addr_t phys= , size_t size) =20 static int dma_set_decrypted(struct device *dev, void *vaddr, size_t size) { - if (!force_dma_unencrypted(dev)) + if (!force_dma_unencrypted(dev) || is_swiotlb_for_alloc(dev)) return 0; return set_memory_decrypted((unsigned long)vaddr, PFN_UP(size)); } @@ -88,7 +88,7 @@ static int dma_set_encrypted(struct device *dev, void *va= ddr, size_t size) { int ret; =20 - if (!force_dma_unencrypted(dev)) + if (!force_dma_unencrypted(dev) || is_swiotlb_for_alloc(dev)) return 0; ret =3D set_memory_encrypted((unsigned long)vaddr, PFN_UP(size)); if (ret) --=20 2.53.0.1185.g05d4b7b318-goog From nobody Wed Apr 1 09:43:48 2026 Received: from mail-wr1-f73.google.com (mail-wr1-f73.google.com [209.85.221.73]) (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 D45E83254A3 for ; Mon, 30 Mar 2026 14:51:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774882295; cv=none; b=BpKYnoXsCQVmz4ajYAYHHSUXAlUlVERxt2ZgyQYnXg8Hvv++NDCV7lXvZVZnH6mYSICilJEtF3D/YWm1a38IjnPvIHPg1oPARws9ynIObcQmjd2dj4Q02q3bC9LVvJmxhzp9hcquwzaM0F1c8yRdd1PbsqOBUglSqb8L7r42z44= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774882295; c=relaxed/simple; bh=opY1fUPRtapU04S/fxJwBSImHDWEYci8EXTK7TGZOuw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=hAKWj8ML2g6dF5q6u5w+o6B0a6zDMLp74ORJypZAXcsnzoCmxS9DVGRComQdUzYXiTUbtKTmOox6Ab+qnzHXz508M0dsYJC6CrnnwVUCO323kidEpT7N/bGeVR4ndmRwj8QxcjvDwnW2Nw+Xi2Q2APFJURXOIqTFx5gKwyDdOK4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--smostafa.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=fP3uq84x; arc=none smtp.client-ip=209.85.221.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--smostafa.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="fP3uq84x" Received: by mail-wr1-f73.google.com with SMTP id ffacd0b85a97d-43d06133455so215383f8f.3 for ; Mon, 30 Mar 2026 07:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774882292; x=1775487092; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=BX6TQo3VfBDX89+YXqbdRt16ZmxOEjXJvCtPOwdDiyI=; b=fP3uq84xFgb1aO8DQQtXge5TLboHOti3s4sitOtCyudBqqKrw0OvWXKOMd1g3ctSHK xSeY5ODymiMABUMQ9RQUDpG8kiDFBMZwlBUGBN6C+WTA5GikSj936bmSVniNah5LqQQF 3cO/UD1yNsfKF4gHK/S0PWEzp/da2XFNRyNDVs30HvChVR31vJWzLW98zymLnD8NOVfH 9pGAodvM7YfOvGuQirUM2UC8IXf34jXcmu08sFcMvmsidzqGxvTUi9Sd86qzi3ZcXuZ2 bPUz0WYNj1Ykhs+dGyVEcNYCvZKXrJXq+PHcqIuBBDTpmE8om+FE2zucq5Cynin9aPdK DXjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774882292; x=1775487092; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BX6TQo3VfBDX89+YXqbdRt16ZmxOEjXJvCtPOwdDiyI=; b=dvQxfO2z2TSy+cAVFJOuCPLY5uagj+TJ2BvICxo56vX8YgESQcI7Oc5uZR9nSwTkyi SwAQUumXCIw+CqryEf4CIIGbmfl++dF0tHpIeJskpTMdmTvUw8cViZ7L+cPmZNJKDJxL cqVROjuZ+pf+KsXFpt2sXhNXfEO3hMjLe1o3U13rbK4jmrR/gjtaNxp95jug5tKfOgYt lLkI1GewYO0ucHeELZUe+1SBeYEOqiAvTwwzaY+CVVdjN0Yk4qiSQHVDT1WLa7TWnMyz kANKQi6xTcuc56az2biM2fN5qrr2s7HX9Cfv49DbFO233fJgXTCoKAEQybXyW33tavrI G8Bw== X-Forwarded-Encrypted: i=1; AJvYcCW0lbxqUvoXB3utyLvQ/rL8iF4Van1p8itaSySedagoH6antzlUHAS4qWj3PcRSNPXgcPoy5fzqJcRI8Vk=@vger.kernel.org X-Gm-Message-State: AOJu0YwN4X53cTJt5cYmc6nHQPzwE94p4r6HLiVv3pwPWn8IYVNyUxyQ OaYR2tvSKkPhUyzqRzICBamvkZ+62sseGINlvsGzGxTNktfvkJaVW6uwbvGy00+e1zdd+hrU0gu lh38GA353iTpktw== X-Received: from wrpb6.prod.google.com ([2002:adf:f246:0:b0:43c:fd0c:97cf]) (user=smostafa job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:40ca:b0:43c:fe0e:5bc5 with SMTP id ffacd0b85a97d-43cfe0e5dd2mr8630014f8f.4.1774882292005; Mon, 30 Mar 2026 07:51:32 -0700 (PDT) Date: Mon, 30 Mar 2026 14:50:40 +0000 In-Reply-To: <20260330145043.1586623-1-smostafa@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260330145043.1586623-1-smostafa@google.com> X-Mailer: git-send-email 2.53.0.1185.g05d4b7b318-goog Message-ID: <20260330145043.1586623-3-smostafa@google.com> Subject: [RFC PATCH v2 2/5] dma-mapping: Use the correct phys_to_dma() for DMA_RESTRICTED_POOL From: Mostafa Saleh To: iommu@lists.linux.dev, linux-kernel@vger.kernel.org Cc: robin.murphy@arm.com, m.szyprowski@samsung.com, will@kernel.org, maz@kernel.org, suzuki.poulose@arm.com, catalin.marinas@arm.com, jiri@resnulli.us, jgg@ziepe.ca, aneesh.kumar@kernel.org, Mostafa Saleh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" As restricted dma pools are always decrypted, in swiotlb.c it uses phys_to_dma_unencrypted() for address conversion. However, in DMA-direct, calls to phys_to_dma_direct() with force_dma_unencrypted() returning false, will fallback to phys_to_dma() which is inconsistent for memory allocated from restricted dma pools. Fixes: f4111e39a52a ("swiotlb: Add restricted DMA alloc/free support") Signed-off-by: Mostafa Saleh --- kernel/dma/direct.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 27d804f0473f..1a402bb956d9 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -26,7 +26,7 @@ u64 zone_dma_limit __ro_after_init =3D DMA_BIT_MASK(24); static inline dma_addr_t phys_to_dma_direct(struct device *dev, phys_addr_t phys) { - if (force_dma_unencrypted(dev)) + if (force_dma_unencrypted(dev) || is_swiotlb_for_alloc(dev)) return phys_to_dma_unencrypted(dev, phys); return phys_to_dma(dev, phys); } --=20 2.53.0.1185.g05d4b7b318-goog From nobody Wed Apr 1 09:43:48 2026 Received: from mail-ed1-f73.google.com (mail-ed1-f73.google.com [209.85.208.73]) (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 8E4B72F6591 for ; Mon, 30 Mar 2026 14:51:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774882302; cv=none; b=btGbkullOjTLLrvtXpUAGshqYs+I7O/G89B2O7vnMRha3JiXaNOfucd5hsYOOiwMzBe/YCq3A1zE4HYXZEYdCwzHUZDaQlr337yYvv7xUnJME96H5XW0JqD8FVCQT4tekMG0Wnd4+5yffYL9lCCBlH0SSfO//SUEetG/o5j0mzY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774882302; c=relaxed/simple; bh=blqPOdpFL9rgBFWqDEnMj0GQkW/94UGmtk6kjXsP/Ro=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=cG1XbyTit+CcNVa+NGqk3+t2BCzhh6j1+wUxoKgbcmng/RVtD37RNtsPIy8oYOGgc4Z74/Rgnh1I4fCwZiffK1xEXy8Rf/H+MHJAOORmFvN0gq4XCCiOT29hGavTvvZNYq3a4L6pdX7RnHGdkPsqS/nSZvVW8//gILWCgQQx6TM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--smostafa.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=SR8lOSnR; arc=none smtp.client-ip=209.85.208.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--smostafa.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="SR8lOSnR" Received: by mail-ed1-f73.google.com with SMTP id 4fb4d7f45d1cf-66802fe028aso5052321a12.0 for ; Mon, 30 Mar 2026 07:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774882299; x=1775487099; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=72NJpUNwgOjfnU3080YLnTh3b+2pO2EMQ9vDQPCjWLY=; b=SR8lOSnRRs3E/mXBHADog4MsVdE7thNhlDmEiaIgKOCII3lxGJPGAJTw3S5z3RaK29 xUehwJH3p2+3oSYMOVxLyErBAPmVq1M2vsMZH8fAxYKRXFD1M1VqhQFfGQesc6gjyZQK siMFKMBBDDasJ/ebDP6TnDfyTir7xsFwNaQtTc60iX2zAmHee8FDk/FQtwX+SFnSaUr5 TK9uXpgMDko64jdf8n2lvG5W0guBMxPTDw21I3bskG7nw6OjmfRO5U9eL+7/+1jAkAmM 9zs9RfTXpTUCIwVItshXxgLLQQrymv/Hekq9nd9TcrIt+YIRwSK8Rci9en6nT21dorXC jpXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774882299; x=1775487099; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=72NJpUNwgOjfnU3080YLnTh3b+2pO2EMQ9vDQPCjWLY=; b=m9OewQhDe3R2THpDD6xVe/VCz6y+PTvnjxFhzcmhEIX7rtLCISXskQYCvQRFDu+BMP N89TD6hKwh8fQumX+jvFS8b5EYxVQm7hZZiCXOZiJDcVUyS9ZupxiTv554sEgJdNjJrf QnUfLysfn9qjvDEZCSOner8RYLZ4oW+IkRQ6QTXySvu8IZFkCUHm9yy365kGHWg3Z0CZ q3X4ikFpBTZ0mbfLsqpeNwuRLABvfq4A6WJX0RKkzaBn708d3+NKndh0qSMi38cWH9ss DRAmLi0NZMEDFBxpMALR5NEpj+5JdlUAIf7Y19Tnhts1kU1NrAFz2/gJxWbq5UF9Xf/o RMFQ== X-Forwarded-Encrypted: i=1; AJvYcCUgTfOA97yNhRv9WvSnef0h0YtHCv7uyWa9a1OkCJUdSWUZirXN31X72zsHcyZodTSN2zioJuM7LetRFcA=@vger.kernel.org X-Gm-Message-State: AOJu0YzstFY8HFD2gg5bNMHmF6qoyld1pg2ptcGIH60+ZyfnqniA8hix htVx5syfa6z6KZgJ43CzQ3FEc2iv9cDjtGVA5gYfh7Wu6zTBJJ53A2XBQ3GEG5lJxIwBPVqCRHH cc3jHOOEufL4EFA== X-Received: from edcz13.prod.google.com ([2002:a05:6402:35cd:b0:66b:eb4d:db46]) (user=smostafa job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6402:510d:b0:66c:7ab:1445 with SMTP id 4fb4d7f45d1cf-66c07ab16a4mr1183900a12.7.1774882298813; Mon, 30 Mar 2026 07:51:38 -0700 (PDT) Date: Mon, 30 Mar 2026 14:50:41 +0000 In-Reply-To: <20260330145043.1586623-1-smostafa@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260330145043.1586623-1-smostafa@google.com> X-Mailer: git-send-email 2.53.0.1185.g05d4b7b318-goog Message-ID: <20260330145043.1586623-4-smostafa@google.com> Subject: [RFC PATCH v2 3/5] dma-mapping: Decrypt memory on remap From: Mostafa Saleh To: iommu@lists.linux.dev, linux-kernel@vger.kernel.org Cc: robin.murphy@arm.com, m.szyprowski@samsung.com, will@kernel.org, maz@kernel.org, suzuki.poulose@arm.com, catalin.marinas@arm.com, jiri@resnulli.us, jgg@ziepe.ca, aneesh.kumar@kernel.org, Mostafa Saleh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" In case memory needs to be remapped on systems with force_dma_unencrypted(), where this memory is not allocated from a restricted-dma pool, this was currently ignored, while only setting the decrypted pgprot in the remapped alias. The memory still needs to be decrypted in that case. With memory decryption, don't allow highmem allocations, but that shouldn't be a problem on such modern systems. Reported-by: Catalin Marinas Fixes: f3c962226dbe ("dma-direct: clean up the remapping checks in dma_dire= ct_alloc") Signed-off-by: Mostafa Saleh --- kernel/dma/direct.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index 1a402bb956d9..a4260689bcc8 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -203,6 +203,7 @@ static void *dma_direct_alloc_no_mapping(struct device = *dev, size_t size, void *dma_direct_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs) { + bool allow_highmem =3D !force_dma_unencrypted(dev); bool remap =3D false, set_uncached =3D false; struct page *page; void *ret; @@ -251,7 +252,7 @@ void *dma_direct_alloc(struct device *dev, size_t size, return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp); =20 /* we always manually zero the memory once we are done */ - page =3D __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO, true); + page =3D __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO, allow_hig= hmem); if (!page) return NULL; =20 @@ -265,6 +266,9 @@ void *dma_direct_alloc(struct device *dev, size_t size, set_uncached =3D false; } =20 + if (dma_set_decrypted(dev, page_address(page), size)) + goto out_leak_pages; + if (remap) { pgprot_t prot =3D dma_pgprot(dev, PAGE_KERNEL, attrs); =20 @@ -278,11 +282,9 @@ void *dma_direct_alloc(struct device *dev, size_t size, ret =3D dma_common_contiguous_remap(page, size, prot, __builtin_return_address(0)); if (!ret) - goto out_free_pages; + goto out_encrypt_pages; } else { ret =3D page_address(page); - if (dma_set_decrypted(dev, ret, size)) - goto out_leak_pages; } =20 memset(ret, 0, size); @@ -300,7 +302,6 @@ void *dma_direct_alloc(struct device *dev, size_t size, out_encrypt_pages: if (dma_set_encrypted(dev, page_address(page), size)) return NULL; -out_free_pages: __dma_direct_free_pages(dev, page, size); return NULL; out_leak_pages: @@ -339,7 +340,12 @@ void dma_direct_free(struct device *dev, size_t size, return; =20 if (is_vmalloc_addr(cpu_addr)) { + void *vaddr =3D page_address(dma_direct_to_page(dev, dma_addr)); + vunmap(cpu_addr); + + if (dma_set_encrypted(dev, vaddr, size)) + return; } else { if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED)) arch_dma_clear_uncached(cpu_addr, size); --=20 2.53.0.1185.g05d4b7b318-goog From nobody Wed Apr 1 09:43:48 2026 Received: from mail-ed1-f74.google.com (mail-ed1-f74.google.com [209.85.208.74]) (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 628B8329395 for ; Mon, 30 Mar 2026 14:51:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774882309; cv=none; b=LZJTah8rgJwQyiCA/ru/WNHwLLf4fwKl/SASMl0pOpXzkYq4j5onPdQjOKAZGzZtPAad4549fZOb4ZupCbBpF2qucOYhdyb8fJpIdF+RpEShywgUFuPJXgpathJta0kg2r/J2kNMhGwbZUQdwtRMIn7Ke7wBDNwTweWPXAWfOAc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774882309; c=relaxed/simple; bh=AACj5Q1Te+cllukPGpODl/FrzLJ7iqJVyQNdhpktZMg=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=BW0HhJO9w0OQ16nUkGA5EPyTFLsZSjE6aoi1/A4Za3WPPjo7tvSPnxx+P0RlCC7nqFjPrLiviWy1qWhM1sZ4EyCENySctBs/yemMXQXN9qcXAK813aWbGTAOgWs2ghDwYYYY1rRQBYi+v5OuJPJzASotErKNTNDInGZwsq4UJ4c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--smostafa.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=dnqKq3J8; arc=none smtp.client-ip=209.85.208.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--smostafa.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="dnqKq3J8" Received: by mail-ed1-f74.google.com with SMTP id 4fb4d7f45d1cf-662f12c2747so5705194a12.3 for ; Mon, 30 Mar 2026 07:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774882306; x=1775487106; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=mU7Mp0JnalK0jHaAyT2ZTi+XzZ8j8BilljX0NIW7h+I=; b=dnqKq3J8jRQjlsWoUMtwJEZj5mFEv40srQ85knBouHtL48H8SVqb77GK4CDbYzANDE A3HWZFJ50Iwb2YDt8H4FBe+epFhq5hlnPx4wGc0sro2x6Iw/v6LHuQcmTP+V6h8AXMp7 6Oj3XVjV9frOVksn7zJf71dKj9a0sWM+pDIdDBXBogvWPvpBIIW02qUBCse9lnUx4/7t dkati6DitKbV6Br5e1TKsA2h3cZoYr1OZqF6AjuQX/zDHgSS6EDoTz0Z8oQqRWrWpz9S Jsn8/40Wuat3aHl7mI9a1c9jEmN9ds8I5jQhcz+gIK8kVnjknT3l6AjLam5V2qQgdeTm CRdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774882306; x=1775487106; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=mU7Mp0JnalK0jHaAyT2ZTi+XzZ8j8BilljX0NIW7h+I=; b=UTtrk4gZKr5N6/A2Bw9WjLNJ8AwKUAwzXwWo4sKoRUDmM9juTadvGwV+jPnQx/CQfM 4WRXOdfpcsXCiC+gxXdtGt1EkSawvYq+Y6W4MLd2qdieKvEos2FrB9LcnmeaIQZ3ezwI ac8/q4Vx0THe6iO/gKrTqc+ARaQZTU73WS15gDUrjXn1nb5tND+TurmjgBxEOiEOZryl 4Oh6seLg7Eljw1wBoSdvQ/RSOja1awwZTLt7EEKTwBvApaTfxB/xmNJHE3FPJbFlJe9K 8yjJCqqeLCx46R5G1zajGqhkRY3KDU1t57TeQUsWwWyjjj4eplVgTF54SL6JkCS1JSo6 ++tw== X-Forwarded-Encrypted: i=1; AJvYcCWk0B5vcrzGlfLzZcadTweD8Ix4OfkhLcKs5LR6F8fLFHa+PV4yfn9MM5P97jtUrRdnPzuoL6BcHarcbM8=@vger.kernel.org X-Gm-Message-State: AOJu0YxrtdMnMuqDCI2VyKn+Xuc8mVuHP+CqOE4S62yZlsTclq4lmSTr NvZSskTvxXY9hOJ6bGjB5TlDOq0lFDwBelLJJ7MDsou9OvABEcMI/CSMPRNxEnBKw4fYhOC/x10 Yzt4ucJ/cChvDcA== X-Received: from edeb19.prod.google.com ([2002:a05:6402:2793:b0:66b:62f:dced]) (user=smostafa job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6402:a0d5:b0:66b:aa56:ee5c with SMTP id 4fb4d7f45d1cf-66baa56f065mr3617472a12.28.1774882305564; Mon, 30 Mar 2026 07:51:45 -0700 (PDT) Date: Mon, 30 Mar 2026 14:50:42 +0000 In-Reply-To: <20260330145043.1586623-1-smostafa@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260330145043.1586623-1-smostafa@google.com> X-Mailer: git-send-email 2.53.0.1185.g05d4b7b318-goog Message-ID: <20260330145043.1586623-5-smostafa@google.com> Subject: [RFC PATCH v2 4/5] dma-mapping: Refactor memory encryption usage From: Mostafa Saleh To: iommu@lists.linux.dev, linux-kernel@vger.kernel.org Cc: robin.murphy@arm.com, m.szyprowski@samsung.com, will@kernel.org, maz@kernel.org, suzuki.poulose@arm.com, catalin.marinas@arm.com, jiri@resnulli.us, jgg@ziepe.ca, aneesh.kumar@kernel.org, Mostafa Saleh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" At the moment dma-direct deals with memory encryption in 2 cases - Pre-decrypted restricted dma-pools - Arch code through force_dma_unencrypted() In the first case, the memory is owned by the pool and the decryption is not managed by the dma-direct. However, it should be aware of it to use the appropriate phys_to_dma* and page table prot. For the second case, it=E2=80=99s the job of the dma-direct to manage the decryption of the allocated memory. As there have been bugs in this code due to wrong or missing checks and there are more use cases coming for memory decryption, we need more robust checks in the code to abstract the core logic, so introduce some local helpers: - dma_external_decryption(): For pages decrypted but managed externally - dma_owns_decryption(): For pages need to be decrypted and managed by dma-direct - is_dma_decrypted(): To check if memory is decrypted Note that this patch is not a no-op as there are some subtle changes which are actually theoretical bug fixes in dma_direct_mmap() and dma_direct_alloc() where the wrong prot might be used for remap. Signed-off-by: Mostafa Saleh --- kernel/dma/direct.c | 37 +++++++++++++++++++++++++++---------- 1 file changed, 27 insertions(+), 10 deletions(-) diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c index a4260689bcc8..1078e1b38a34 100644 --- a/kernel/dma/direct.c +++ b/kernel/dma/direct.c @@ -23,10 +23,27 @@ */ u64 zone_dma_limit __ro_after_init =3D DMA_BIT_MASK(24); =20 +/* Memory is decrypted and managed externally. */ +static inline bool dma_external_decryption(struct device *dev) +{ + return is_swiotlb_for_alloc(dev); +} + +/* Memory needs to be decrypted by the dma-direct layer. */ +static inline bool dma_owns_decryption(struct device *dev) +{ + return force_dma_unencrypted(dev) && !dma_external_decryption(dev); +} + +static inline bool is_dma_decrypted(struct device *dev) +{ + return force_dma_unencrypted(dev) || dma_external_decryption(dev); +} + static inline dma_addr_t phys_to_dma_direct(struct device *dev, phys_addr_t phys) { - if (force_dma_unencrypted(dev) || is_swiotlb_for_alloc(dev)) + if (is_dma_decrypted(dev)) return phys_to_dma_unencrypted(dev, phys); return phys_to_dma(dev, phys); } @@ -79,7 +96,7 @@ bool dma_coherent_ok(struct device *dev, phys_addr_t phys= , size_t size) =20 static int dma_set_decrypted(struct device *dev, void *vaddr, size_t size) { - if (!force_dma_unencrypted(dev) || is_swiotlb_for_alloc(dev)) + if (!dma_owns_decryption(dev)) return 0; return set_memory_decrypted((unsigned long)vaddr, PFN_UP(size)); } @@ -88,7 +105,7 @@ static int dma_set_encrypted(struct device *dev, void *v= addr, size_t size) { int ret; =20 - if (!force_dma_unencrypted(dev) || is_swiotlb_for_alloc(dev)) + if (!dma_owns_decryption(dev)) return 0; ret =3D set_memory_encrypted((unsigned long)vaddr, PFN_UP(size)); if (ret) @@ -203,7 +220,7 @@ static void *dma_direct_alloc_no_mapping(struct device = *dev, size_t size, void *dma_direct_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs) { - bool allow_highmem =3D !force_dma_unencrypted(dev); + bool allow_highmem =3D !dma_owns_decryption(dev); bool remap =3D false, set_uncached =3D false; struct page *page; void *ret; @@ -213,7 +230,7 @@ void *dma_direct_alloc(struct device *dev, size_t size, gfp |=3D __GFP_NOWARN; =20 if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) && - !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev)) + !is_dma_decrypted(dev)) return dma_direct_alloc_no_mapping(dev, size, dma_handle, gfp); =20 if (!dev_is_dma_coherent(dev)) { @@ -247,7 +264,7 @@ void *dma_direct_alloc(struct device *dev, size_t size, * Remapping or decrypting memory may block, allocate the memory from * the atomic pools instead if we aren't allowed block. */ - if ((remap || force_dma_unencrypted(dev)) && + if ((remap || dma_owns_decryption(dev)) && dma_direct_use_pool(dev, gfp)) return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp); =20 @@ -272,7 +289,7 @@ void *dma_direct_alloc(struct device *dev, size_t size, if (remap) { pgprot_t prot =3D dma_pgprot(dev, PAGE_KERNEL, attrs); =20 - if (force_dma_unencrypted(dev)) + if (is_dma_decrypted(dev)) prot =3D pgprot_decrypted(prot); =20 /* remove any dirty cache lines on the kernel alias */ @@ -314,7 +331,7 @@ void dma_direct_free(struct device *dev, size_t size, unsigned int page_order =3D get_order(size); =20 if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) && - !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev)) { + !is_dma_decrypted(dev)) { /* cpu_addr is a struct page cookie, not a kernel address */ dma_free_contiguous(dev, cpu_addr, size); return; @@ -362,7 +379,7 @@ struct page *dma_direct_alloc_pages(struct device *dev,= size_t size, struct page *page; void *ret; =20 - if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp)) + if (dma_owns_decryption(dev) && dma_direct_use_pool(dev, gfp)) return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp); =20 page =3D __dma_direct_alloc_pages(dev, size, gfp, false); @@ -530,7 +547,7 @@ int dma_direct_mmap(struct device *dev, struct vm_area_= struct *vma, int ret =3D -ENXIO; =20 vma->vm_page_prot =3D dma_pgprot(dev, vma->vm_page_prot, attrs); - if (force_dma_unencrypted(dev)) + if (is_dma_decrypted(dev)) vma->vm_page_prot =3D pgprot_decrypted(vma->vm_page_prot); =20 if (dma_mmap_from_dev_coherent(dev, vma, cpu_addr, size, &ret)) --=20 2.53.0.1185.g05d4b7b318-goog From nobody Wed Apr 1 09:43:48 2026 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (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 C8D483264EF for ; Mon, 30 Mar 2026 14:51:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774882314; cv=none; b=cayPlnSkVs0QqWot92SfbImQFUGB1+bznoiXug5ByMp6qi7nJJis8v6V+crv285YOU85/YjxyC9TtUBjWzLS80irkwUbv/rfEAeE7UdeFbeAL0znAMBfrLpM+sjWYJSAN9lIPCuRi4UU+Qt+N6JsRdQ97lGpB+Ai7ANm5hKdKV4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774882314; c=relaxed/simple; bh=KCuGLCDrnXVXD6TiJbaeXO/0PpT9+aGSay1SncYRiiA=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=FA5YSzODKvGRdV7WNwD68sM9xrfDE3Jzh6OCbwssC94bQ3AJWw6W9+XaaVXZYwtRFKgowqAEA0/MrkaSrrZzHOcfYwnHolEf/PpIFwotlE/DXVQ9R6T0tNSvdROYq5G5EtPalcIjqedHOP2EHJzsrIaoO7S6KnynbFe4VmNG5x8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--smostafa.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=GDq44Z3o; arc=none smtp.client-ip=209.85.128.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--smostafa.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="GDq44Z3o" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-486fa35b005so56508525e9.2 for ; Mon, 30 Mar 2026 07:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1774882311; x=1775487111; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=6tg98HiSUgt/GbbZQxDpMM7Lbcp5/dXhobOqHvI8sRU=; b=GDq44Z3ogiKf7du5sxgo6I6NGoO/6OObg09G2eYfNb6Bqt9RFd2sEeZOJr2UEumk1X yRQ8/Lmljs/sgjBinGbQ+hYKnAcij4S6CCcjCvOdXyOMB1KUTNAeS0IG1V59VtrJvKAe ZfmohCDBwrFxVtlfKBMCkM6dpDOadsUsSADdOUWHKMm7j5k4ckmR5R6j0wZs1MuuXQ29 AaJ1apnGOG2uivaPivvcxippT8ZZkuYQQ7OOgDPHIjgDVtZHsybujh8/KuNcPya8Wy5t 30/eFUgR6voWAMdfSPNKF5++bS1QeQm1bRIGGm4d74Bho8OBlqEp4uyaoG/Ua/8451Xc Rm0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774882311; x=1775487111; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6tg98HiSUgt/GbbZQxDpMM7Lbcp5/dXhobOqHvI8sRU=; b=mERW2ybaI9mO0JVn8ftoDLdRLq0W2wO/vO02Sci1E8bvHMj6y9oDaZPLP/bEcyFh4y vpNWyilTdy19C+XZl6h7g7GRsqnZl8SrPCHGeIHudaYKRP21qP2gPwN4dMQ4SZdsbNXy LKvcyUd7zrUHy74O7SPR767XRRzKpcCXbrUmr/4Cxq8SyM/XKW4REagL4OlvBWr8/5px +xOmwIXJz2TeGD4kg47ihh6ynE44WS+HYqExWHOv9WFXBcdRxP1E1DJ1T6ew2enc6LNA VWjPQJRyN6B0xBzh0he+Ys93/ZCwLUTQdxzRXbjGEy3/eFCmPqyo9PBtavcJhynb9dbu CH5w== X-Forwarded-Encrypted: i=1; AJvYcCWfZFHBSfn6iNPETAePVq8RRGY2wrnqiIUZAnJrvXwBvzv53I3C7mhM9J8Q0aTLiS8dXcTw03kOK4Qcges=@vger.kernel.org X-Gm-Message-State: AOJu0YwZ2P0t5Ai+zege0so8hiJoBbmld7HMDqzpTCUCUH2AZVJZcNyU dpD6QOwHDlvcOeNam1Uvt8/tuoVN7t93H8J6al74gH2IaIQTOawp5B5TVVp4si5bqeGZWs8nB2B 2v8bgn7qaItYHIg== X-Received: from wmbz18.prod.google.com ([2002:a05:600c:c092:b0:487:38f4:95a5]) (user=smostafa job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:3d87:b0:486:5f71:5829 with SMTP id 5b1f17b1804b1-48727d5a307mr212298425e9.5.1774882311107; Mon, 30 Mar 2026 07:51:51 -0700 (PDT) Date: Mon, 30 Mar 2026 14:50:43 +0000 In-Reply-To: <20260330145043.1586623-1-smostafa@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260330145043.1586623-1-smostafa@google.com> X-Mailer: git-send-email 2.53.0.1185.g05d4b7b318-goog Message-ID: <20260330145043.1586623-6-smostafa@google.com> Subject: [RFC PATCH v2 5/5] dma-mapping: Add doc for memory encryption From: Mostafa Saleh To: iommu@lists.linux.dev, linux-kernel@vger.kernel.org Cc: robin.murphy@arm.com, m.szyprowski@samsung.com, will@kernel.org, maz@kernel.org, suzuki.poulose@arm.com, catalin.marinas@arm.com, jiri@resnulli.us, jgg@ziepe.ca, aneesh.kumar@kernel.org, Mostafa Saleh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Add a document for memory encryption usage with dma-direct. Signed-off-by: Mostafa Saleh --- .../core-api/dma-direct-memory-encryption.rst | 77 +++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 Documentation/core-api/dma-direct-memory-encryption.rst diff --git a/Documentation/core-api/dma-direct-memory-encryption.rst b/Docu= mentation/core-api/dma-direct-memory-encryption.rst new file mode 100644 index 000000000000..a780279292b5 --- /dev/null +++ b/Documentation/core-api/dma-direct-memory-encryption.rst @@ -0,0 +1,77 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +DMA Direct and Memory Encryption Integration +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D + +Introduction +------------ +Modern platforms introduce memory encryption features (e.g., AMD SEV, Inte= l TDX, +ARM CCA, and pKVM) typically for CoCo when running protected virtual machi= nes. + +These guests typically boot with their memory encrypted by default. + +In some cases this memory needs to be accessed by the untrusted host or the +VMM which then requires this memory to be decrypted. One typical case is +dealing with emulated device (e.g., virtio) which are handled by direct-dma +code as these devices are not behind an IOMMU. + +That means, the memory used by these devices must be decrypted before acce= ssed +by the untrusted host. + +It must be clarified that encrypted/decrypted may not always be +cryptographic; in a broader sense, a decrypted page means that it is +accessible or "shared" with the untrusted host. + +Ownership +--------- +The direct-dma layer deals with memory encryption in two distinct scenario= s: + +1. **Externally Managed Decryption (e.g., Restricted DMA Pools)** + In some setups (like a device restricted to a specific SWIOTLB pool, i.= e., + `DMA_RESTRICTED_POOL`), an entire region of memory is pre-decrypted dur= ing + boot or pool initialization. The memory is owned by the pool, and the + transitions (encryption/decryption) are **not** managed by direct-dma on + a per-allocation basis. + See Documentation/core-api/swiotlb.rst + +2. **DMA Direct Managed Decryption (e.g., `force_dma_unencrypted()`)** + For standard coherent DMA allocations the direct-dma layer is explicitly + responsible for managing the decryption. It must decrypt the pages upon + allocation and re-encrypt them upon freeing. + +To cleanly separate these concerns, the core logic is abstracted via three +internal helpers: + +* ``dma_external_decryption(dev)``: Returns true if the pages are decrypte= d but + managed externally. For example, if the device allocates from a restrict= ed + DMA pool. +* ``dma_owns_decryption(dev)``: Returns true if the pages need to be expli= citly + decrypted and managed by the direct-dma layer (i.e., the architecture fo= rces + unencrypted DMA, and it's not handled by an external pool). +* ``is_dma_decrypted(dev)``: Returns true if the memory being used is in a + decrypted state, regardless of who manages it. + +Addressing and Page Protections +------------------------------- +When memory is decrypted (whether externally or by direct-dma), the layer = must +adjust physical-to-DMA address conversions and page protections: + +* **DMA Address Conversion:** + Decrypted memory often requires a specific bit to be cleared or set in t= he DMA + address (e.g., stripping the encryption bit). If ``is_dma_decrypted(dev)= `` is + true, the conversion uses ``phys_to_dma_unencrypted()`` instead of the s= tandard + ``phys_to_dma()``. + +* **Page Protections (Remap and Mmap):** + When remapping decrypted pages into the kernel virtual address space (vm= alloc) + or mapping them to user space via ``mmap()``, the page protection attrib= utes + must reflect the decrypted state. If ``is_dma_decrypted(dev)`` is true, = the + layer applies ``pgprot_decrypted(prot)`` to ensure the CPU accesses the = memory + with the correct encryption attributes. + +Notes +----- +In many cases when memory encryption/decryption fails the page will be lea= ked, +that's was added for TDX, where ``set_memory_encrypted()`` or +``set_memory_decrypted()``may fail while the page remains shared. --=20 2.53.0.1185.g05d4b7b318-goog