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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 95454C3ABAA for ; Fri, 2 May 2025 14:02:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=3kujlEZKqpXdQlEls+Dn4PDnSy2MwOYRpOQ+zqD+3BY=; b=uJKBhGC9nIbNLeAn0SMBzEKy1j l4MROveb7ggvsuBxVcF84p3b/fZjoM+cUJmXYe7KUgUmg9ycJbRBAt11yl1s6AkIxtyvYwAi9Ab1L bhoZSFpBSifY7tuvp/un8DxAZWFkqjo6ZB/ypuwGbk3oeAkNBmHT635NuTIX7m3IDdHd1UBpOd10+ ogg2k5W+s74oIDg88c5vjOUn/PRkk2obLKsyFC34bXHcXbQAq3ZwF7XopnEqXxCPInwnOGTri+4Lr 9/dwT5y3ThzpJG+K5/fMIRTdansMAzk48LdB+gF0+Jd4lK3O8m+ZFTP+4BFr1aXgR8ovL7lIXkSma c/8OPkHg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uAqxa-000000027y0-0BAZ; Fri, 02 May 2025 14:01:50 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uAqvc-000000027iz-1g2I for linux-arm-kernel@lists.infradead.org; Fri, 02 May 2025 13:59:49 +0000 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 9830A1688; Fri, 2 May 2025 06:59:38 -0700 (PDT) Received: from [10.1.196.40] (e121345-lin.cambridge.arm.com [10.1.196.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D14073F673; Fri, 2 May 2025 06:59:41 -0700 (PDT) Message-ID: <6a33e85f-6b60-4260-993d-974dd29cf8e6@arm.com> Date: Fri, 2 May 2025 14:59:40 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 06/14] tee: implement protected DMA-heap To: Jens Wiklander , linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org, op-tee@lists.trustedfirmware.org, linux-arm-kernel@lists.infradead.org Cc: Olivier Masse , Thierry Reding , Yong Wu , Sumit Semwal , Benjamin Gaignard , Brian Starkey , John Stultz , "T . J . Mercier" , =?UTF-8?Q?Christian_K=C3=B6nig?= , Sumit Garg , Matthias Brugger , AngeloGioacchino Del Regno , azarrabi@qti.qualcomm.com, Simona Vetter , Daniel Stone , Rouven Czerwinski References: <20250502100049.1746335-1-jens.wiklander@linaro.org> <20250502100049.1746335-7-jens.wiklander@linaro.org> From: Robin Murphy Content-Language: en-GB In-Reply-To: <20250502100049.1746335-7-jens.wiklander@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250502_065948_698274_E660FB28 X-CRM114-Status: GOOD ( 17.76 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 02/05/2025 10:59 am, Jens Wiklander wrote: > Implement DMA heap for protected DMA-buf allocation in the TEE > subsystem. > > Restricted memory refers to memory buffers behind a hardware enforced > firewall. It is not accessible to the kernel during normal circumstances > but rather only accessible to certain hardware IPs or CPUs executing in > higher or differently privileged mode than the kernel itself. This > interface allows to allocate and manage such protected memory buffers > via interaction with a TEE implementation. > > The protected memory is allocated for a specific use-case, like Secure > Video Playback, Trusted UI, or Secure Video Recording where certain > hardware devices can access the memory. > > The DMA-heaps are enabled explicitly by the TEE backend driver. The TEE > backend drivers needs to implement protected memory pool to manage the > protected memory. [...]> +static struct sg_table * > +tee_heap_map_dma_buf(struct dma_buf_attachment *attachment, > + enum dma_data_direction direction) > +{ > + struct tee_heap_attachment *a = attachment->priv; > + int ret; > + > + ret = dma_map_sgtable(attachment->dev, &a->table, direction, > + DMA_ATTR_SKIP_CPU_SYNC); If the memory is inaccessible to the kernel, what does this DMA mapping even mean? What happens when it tries to perform cache maintenance or bounce-buffering on inaccessible memory (which presumably doesn't even have a VA if it's not usable as normal kernel memory)? If we're simply housekeeping the TEE's resources on its behalf, and giving it back some token to tell it which resource to go do its thing with, then that's really not "DMA" as far as the kernel is concerned. [...] > +static int protmem_pool_op_static_alloc(struct tee_protmem_pool *pool, > + struct sg_table *sgt, size_t size, > + size_t *offs) > +{ > + struct tee_protmem_static_pool *stp = to_protmem_static_pool(pool); > + phys_addr_t pa; > + int ret; > + > + pa = gen_pool_alloc(stp->gen_pool, size); > + if (!pa) > + return -ENOMEM; > + > + ret = sg_alloc_table(sgt, 1, GFP_KERNEL); > + if (ret) { > + gen_pool_free(stp->gen_pool, pa, size); > + return ret; > + } > + > + sg_set_page(sgt->sgl, phys_to_page(pa), size, 0); Where does "pa" come from here (i.e. what's the provenance of the initial "paddr" passed to tee_protmem_static_pool_alloc())? In general we can't call {phys,pfn}_to_page() an arbitrary addresses without checking pfn_valid() first. A bogus address might even crash __pfn_to_page() itself under CONFIG_SPARSEMEM. Thanks, Robin. > + *offs = pa - stp->pa_base; > + > + return 0; > +}