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 1DDF6C369A2 for ; Wed, 9 Apr 2025 13:19:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B734F6B0189; Wed, 9 Apr 2025 09:19:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B230E6B018A; Wed, 9 Apr 2025 09:19:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9ED306B018B; Wed, 9 Apr 2025 09:19:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7ECE16B0189 for ; Wed, 9 Apr 2025 09:19:15 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id A87EF80999 for ; Wed, 9 Apr 2025 13:19:16 +0000 (UTC) X-FDA: 83314561512.15.8307298 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf06.hostedemail.com (Postfix) with ESMTP id 2229E180002 for ; Wed, 9 Apr 2025 13:19:14 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=oYiPNUPN; spf=pass (imf06.hostedemail.com: domain of sumit.garg@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sumit.garg@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744204755; 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=+yFrp1ZF+hh0yGP7lCVX/QPwHtVXDJncz8wZnIlRW68=; b=71/pTXj9Da5ujo807RUVc5WDhuRALMNoR6zikRATIYHHpSC3Nr4njTYCGPZjRdEZ0lK/Uy kq++GRLcGJQQq+D/PJFHnU2EVfIvFuu5sJRJpxq5/asAW8YGYdmBXUyFiS2mpaidQIfIKa L9n3Ed3qM7qK1J0G0iKDNkJ1R/ESPjo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744204755; a=rsa-sha256; cv=none; b=uNuboshj20YdGYSJoo5zTLu8F4jPQjj/j7ZaJ7Z+ibhgg01gR4x147lsPrE2s8u2IeOGTs vf8ZNdrvCYTnPXLVuRN/vcKTyPE6BdLGhA7XVcZOFSD1LD3+Hdi7azJKM1Ou/O1cA/1cLR Gjh3CnpILGpDe/mahc9T5nk/MpeiMVQ= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=oYiPNUPN; spf=pass (imf06.hostedemail.com: domain of sumit.garg@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sumit.garg@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id D2DA2A4994D; Wed, 9 Apr 2025 13:13:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id F353CC4CEE7; Wed, 9 Apr 2025 13:19:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744204754; bh=ny9pPvFJ5Zid+zmKB7nDp5AE59k+FfvC0LsxKtkgDto=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oYiPNUPNRquxwDEcnEDR0gurvjOXJDwRrKViTi0bTN9MxKlniyZtOTGFdtzWnBV1N cxa7dyL3PCVMjnMAnkUQwFkXKbSDqstnaWgawP9OjCBvqdOZFKw4ZkBz6hPax0VboI A7T1OHaAOOXkXNB1CbHV1gxRb7JDlBHSCZQ6fuVw6tMJSbFWpB7TN208lKOod0eTA9 pP7gU8drcOYoeLCgLTU8LZ3BdLL9gkJC/vEyM/tF/0WIwXIpAzNaSYzBvWZnTDDI8b dqX6UPu6kuS3f6ion31atJwZTjavkTM4EmHwnSgbRQspC6GP6JXrA5W6ULuQ/mxonY 7T8sIy5WIw/dQ== Date: Wed, 9 Apr 2025 18:49:03 +0530 From: Sumit Garg To: David Hildenbrand Cc: Jens Wiklander , akpm@linux-foundation.org, rppt@linux.ibm.com, 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, Olivier Masse , Thierry Reding , Yong Wu , Sumit Semwal , Benjamin Gaignard , Brian Starkey , John Stultz , "T . J . Mercier" , Christian =?iso-8859-1?Q?K=F6nig?= , Matthias Brugger , AngeloGioacchino Del Regno , azarrabi@qti.qualcomm.com, Simona Vetter , Daniel Stone , linux-mm@kvack.org Subject: Re: [PATCH v6 09/10] optee: FF-A: dynamic restricted memory allocation Message-ID: References: <20250305130634.1850178-1-jens.wiklander@linaro.org> <20250305130634.1850178-10-jens.wiklander@linaro.org> <561d6050-e24f-4643-806f-8a520e324d11@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <561d6050-e24f-4643-806f-8a520e324d11@redhat.com> X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 2229E180002 X-Stat-Signature: pnxhq5fgp3todtwts3x8jki4xgjccanu X-HE-Tag: 1744204754-702994 X-HE-Meta: U2FsdGVkX18E1kqdBD2ctzjYQKoICOrYv0xtwmVOHsHqQjnL8SFp5w0wj96xMH/NxSKGTJtaO3G10YL8pES5GQVGXTlDaWTG0Wp+PuKLaQuuWo//I/8D8ke/fiWBNQreEHYR3a4i3x0fHvLPtJLyKEbyA/OCRQRmpNsxYSCn4nHU/fARDLgWlWPoEwgbPORi+RwW3rX5+jhqRpkl4Dq4iYKTIN0MKPodFMz4I8Oor1fv3+cARQyrhJRJYJvO/SncBtrxYuSS2lMRjrPmK7oE3zs4hj250Fc6m7dyInFvjF3ANnO2weSeG9O1xklhlQqu+qMbWMU55JXvrEdCzrr6DFrYxbrO7y8cztajJgGvGF644bNbf7Uigsns1lbGqiuNMW5QZjJEbpZRBe2XPRxR5wU5EMmbvyqF8dgLvBtPcnadXdmijQwEuERKZKh2mV+Z+nHvrNRxkoDsAMThu3+u1U73FQQLcwATvx4pmTQ7O4qCpKMPF9kGuEm/aOHJvQFry+XzNAiFCX+4e9t7YZvUYlJIxX7NcT9/9x/r1u/l6Kfh6TeuTl6zWub64pdGvx1HC0mHUFKzAe+N1h5gnn0PZAxkjR+d1YnWXKUXgEJ3RGS8lUSTas2/qzoKLqgQPi2/yz/kkPQHudIkFyKY7tH6bJ0ZqyuDYRRCQ7UoO1ktNZ0+8lx5A6p8UpeS/abobmenKWelnjzh2bEK3EXmMMtHLeGWaYzrrh7R4XGyCqAVnW2PKlre3SaqzqKTUgXDqN86aQM2gKZSkjghK46wJ+jkZytG3uGROntSAREOrzy35E6ZbUZ6GoFT4l5sJ44bBn7tKv67CZJmWA3dBRJ9Zp3OnMk3jDRUTJ2VuKV4OJumKhmmqVxb9uq4vD3kKUXPkETcXq8q8dNhIP14Ymnr5UlCNCfUGSqFvTevA3KkmuTBSPFQbO0Rqlsm3p94yp93YBpZlA6HJk0kUoZax9o5d/K 6vtwMdTJ 9ZC/PnVVkw0ZQQ2gy16KgU2jJR0A9rwZiuyxn6u5BlNlQ1zrEWRxDbXgmU3YWIdnKszWP 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: Thanks David for your response. On Wed, Apr 09, 2025 at 12:01:21PM +0200, David Hildenbrand wrote: > On 01.04.25 12:13, Sumit Garg wrote: > > + MM folks to seek guidance here. > > > > On Thu, Mar 27, 2025 at 09:07:34AM +0100, Jens Wiklander wrote: > > > Hi Sumit, > > > > > > On Tue, Mar 25, 2025 at 8:42 AM Sumit Garg wrote: > > > > > > > > On Wed, Mar 05, 2025 at 02:04:15PM +0100, Jens Wiklander wrote: > > > > > Add support in the OP-TEE backend driver dynamic restricted memory > > > > > allocation with FF-A. > > > > > > > > > > The restricted memory pools for dynamically allocated restrict memory > > > > > are instantiated when requested by user-space. This instantiation can > > > > > fail if OP-TEE doesn't support the requested use-case of restricted > > > > > memory. > > > > > > > > > > Restricted memory pools based on a static carveout or dynamic allocation > > > > > can coexist for different use-cases. We use only dynamic allocation with > > > > > FF-A. > > > > > > > > > > Signed-off-by: Jens Wiklander > > > > > --- > > > > > drivers/tee/optee/Makefile | 1 + > > > > > drivers/tee/optee/ffa_abi.c | 143 ++++++++++++- > > > > > drivers/tee/optee/optee_private.h | 13 +- > > > > > drivers/tee/optee/rstmem.c | 329 ++++++++++++++++++++++++++++++ > > > > > 4 files changed, 483 insertions(+), 3 deletions(-) > > > > > create mode 100644 drivers/tee/optee/rstmem.c > > > > > > > > > > > > > > > > diff --git a/drivers/tee/optee/rstmem.c b/drivers/tee/optee/rstmem.c > > > > > new file mode 100644 > > > > > index 000000000000..ea27769934d4 > > > > > --- /dev/null > > > > > +++ b/drivers/tee/optee/rstmem.c > > > > > @@ -0,0 +1,329 @@ > > > > > +// SPDX-License-Identifier: GPL-2.0-only > > > > > +/* > > > > > + * Copyright (c) 2025, Linaro Limited > > > > > + */ > > > > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > > > > + > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include "optee_private.h" > > > > > + > > > > > +struct optee_rstmem_cma_pool { > > > > > + struct tee_rstmem_pool pool; > > > > > + struct gen_pool *gen_pool; > > > > > + struct optee *optee; > > > > > + size_t page_count; > > > > > + u16 *end_points; > > > > > + u_int end_point_count; > > > > > + u_int align; > > > > > + refcount_t refcount; > > > > > + u32 use_case; > > > > > + struct tee_shm *rstmem; > > > > > + /* Protects when initializing and tearing down this struct */ > > > > > + struct mutex mutex; > > > > > +}; > > > > > + > > > > > +static struct optee_rstmem_cma_pool * > > > > > +to_rstmem_cma_pool(struct tee_rstmem_pool *pool) > > > > > +{ > > > > > + return container_of(pool, struct optee_rstmem_cma_pool, pool); > > > > > +} > > > > > + > > > > > +static int init_cma_rstmem(struct optee_rstmem_cma_pool *rp) > > > > > +{ > > > > > + int rc; > > > > > + > > > > > + rp->rstmem = tee_shm_alloc_cma_phys_mem(rp->optee->ctx, rp->page_count, > > > > > + rp->align); > > > > > + if (IS_ERR(rp->rstmem)) { > > > > > + rc = PTR_ERR(rp->rstmem); > > > > > + goto err_null_rstmem; > > > > > + } > > > > > + > > > > > + /* > > > > > + * TODO unmap the memory range since the physical memory will > > > > > + * become inaccesible after the lend_rstmem() call. > > > > > + */ > > > > > > > > What's your plan for this TODO? I think we need a CMA allocator here > > > > which can allocate un-mapped memory such that any cache speculation > > > > won't lead to CPU hangs once the memory restriction comes into picture. > > > > > > What happens is platform-specific. For some platforms, it might be > > > enough to avoid explicit access. Yes, a CMA allocator with unmapped > > > memory or where memory can be unmapped is one option. > > > > Did you get a chance to enable real memory protection on RockPi board? > > This will atleast ensure that mapped restricted memory without explicit > > access works fine. Since otherwise once people start to enable real > > memory restriction in OP-TEE, there can be chances of random hang ups > > due to cache speculation. > > > > MM folks, > > > > Basically what we are trying to achieve here is a "no-map" DT behaviour > > [1] which is rather dynamic in nature. The use-case here is that a memory > > block allocated from CMA can be marked restricted at runtime where we > > would like the Linux not being able to directly or indirectly (cache > > speculation) access it. Once memory restriction use-case has been > > completed, the memory block can be marked as normal and freed for > > further CMA allocation. > > > > It will be apprciated if you can guide us regarding the appropriate APIs > > to use for un-mapping/mamping CMA allocations for this use-case. > > Can we get some more information why that is even required, so we can decide > if that is even the right thing to do? :) The main reason which I can see is for memory re-use. Although we should be able to carve out memory during boot and then mark it restricted for the entire boot cycle but without re-use. Especially for secure media pipeline use-case where the video buffers can be sufficiently large enough which will benefit from memory re-use. > > Who would mark the memory block as restricted and for which purpose? It will be the higher privileged firmware/Trusted OS which can either be the running on same CPU with higher privileges like Arm TrustZone or a separate co-processor like AMD-TEE etc. The purpose is for secure media pipeline, trusted UI or secure crypto use-cases where essentially the motivation is that the Linux kernel shouldn't be able to access decrypted content or key material in plain format but rather only the allowed peripherals like media pipeline, crypto accelerators etc. able to access them. > > In arch/powerpc/platforms/powernv/memtrace.c we have some arch-specific code > to remove the directmap after alloc_contig_pages(). See > memtrace_alloc_node(). But it's very arch-specific ... Thanks for the reference, we are looking for something like that but with generic code along with capability to remap when the restricted memory block is freed and available for normal kernel usage. -Sumit