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 6B2E9C369A4 for ; Tue, 8 Apr 2025 09:20:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36EE96B0008; Tue, 8 Apr 2025 05:20:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F4916B000A; Tue, 8 Apr 2025 05:20:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 194916B000C; Tue, 8 Apr 2025 05:20:27 -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 F227D6B0008 for ; Tue, 8 Apr 2025 05:20:26 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 263A31CA90E for ; Tue, 8 Apr 2025 09:20:27 +0000 (UTC) X-FDA: 83310330894.24.693CAB7 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf25.hostedemail.com (Postfix) with ESMTP id 444B0A0002 for ; Tue, 8 Apr 2025 09:20:25 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Xm+As+b9; spf=pass (imf25.hostedemail.com: domain of sumit.garg@kernel.org designates 172.234.252.31 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=1744104025; 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=PqVSoMgA7ejuBO+qrLSjuozdGOXpRDYCsKwOXjeKomE=; b=1ac3YxCHXen/p8b61CNrIK4rryrnN9rj4v74qhMEjlpUquQhu/9L2bU5MbH8tAj4UMyRqi jcPjOAildOuKCu5UH/lIiHkrOPerUzNBdoq6lc9rxAp6DYG3eRH5GPlauW21zTKCbQ92AM FegAWYPMM73ViG0xRXQL5Y8bMXDxutQ= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Xm+As+b9; spf=pass (imf25.hostedemail.com: domain of sumit.garg@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=sumit.garg@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744104025; a=rsa-sha256; cv=none; b=oqmaEBC6msR2l+A4fpQPNGaUiH0jZUVelyw7TMdpxZRJd5813BtfDr7jiB8a66NlRjHIj2 iFvaORFHvI+LYf90EeFSjwadOiG9GKBebDRH1sPM6cMeR/MHaEhj6IebKPuBfAAmOmq9Ms MZu6z9YLh3Qh3lo3uxowKdezEf9b6go= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 58B95439DF; Tue, 8 Apr 2025 09:20:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E1B0C4CEE8; Tue, 8 Apr 2025 09:20:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1744104023; bh=oPws6XXa1Q7PyoXErXwLGgOjoJSswMaricVXHxQU9Do=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Xm+As+b9UdgYv/Vwn+Ce+i9sfrkGk17Y9klQ6NCFQJ27qHYHPZPVTJ6cizsC97m6l jsxG8tf+ShISAEgZYJGEFHXKQHRFrfk8EDxFfYvQtRMQ+xH4cJNcX6Jq/Gp0hr4d3Q 2Qns0WjrHSTdjW4z+m+7NyDWRCq6+VDUUrTOR/tykowjfr5AgBVCMs8W/h2txv+XK4 bSfD5neJNSHpkjOlIrfYq/MrXxZs//V5HXvLXbCgsObUkwme7s7yOaHvNqp+sLpirU l6ndy/YReXkpL+EFvfxCa5qHEWjsJ59tlmfxV33V9i2sBltwI6n8dd06ZTpsqJ2rbw nyl390aUzvCpw== Date: Tue, 8 Apr 2025 14:50:13 +0530 From: Sumit Garg To: Jens Wiklander Cc: akpm@linux-foundation.org, david@redhat.com, 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 444B0A0002 X-Stat-Signature: ftguf38ndroan5ny9dfus641aw15g43i X-HE-Tag: 1744104025-653395 X-HE-Meta: U2FsdGVkX1/lxkaL+OwGT4bhpdmXFTu52QpNnzpnZN3JCbnR0Chtbxyq6ffrUBMHI7mg60nYl53ZBAnxKFmhRMMrnsIcr0s46Lay/EHhYYEJUkX+38mqu/74I9tWgOOLAz16dK4KN8TZY8zxfgqI6VI+AeknFCA/V3KmqWC9Lb//9CG+ACwl9Ec2dKY67wfigBGiN6Ljy2EihE5RIeoPiTSdD/OQxRN2SlXxY1LFNysHcSZiI+Imr5ws93tOnUbt5+pDmevN7iSbvwD8fhs1kpYcY758HLguovF1vBttzh+15QttDgdKmMEum2TyXUIFGKYpdVWw1cgIuergFWRmmWDqCD0LXPBMnK3SP2aJwSSXDbBDxfmYihg1SiQXJasomEusut8SZ6zPvE6DYHDjPQoYwZ/rDW62SDS1UAMyMrsIwXVTa7/awIIT6/Y9ed1TVkMq+e1AMIXI15YSdQhIa19INQZppGsglPQeoVPpKBaJLmwmGoiq9mHUf9+YoXupx+UVn/5GPzJTG98PxJ2I4Jzm1BBsz+eH1/V0wotIqDoqeOqOMFiCRxZBneaOgduCamKQO+sP/fWXMb+KKI+xRmdw9AAjT4OJm9G4P17xX8GqS+E6x4c82zhSLWJ4aoLur+4JxvxxoHoyK/DfArtNRRklgYlLJ1Jk1975mPDHsOOlQWegDYVZNPRUHFdGa/XH3pHAa9KX9oJtryNTSrbHRTh7wemUD4toWgNMb1Wno2RHBG0vkxUWcPn4097mf/XfuznmaJ4ykaiHWRTWAuCvBuP4gXdcASUYCBICka+KcFaRwi4umJVWMVlTVrxNW0WeRIWmWA9j1OZQzRGad7Qst0ubO+Bumb0tfjpziC9f3US5mIZpAhq1blSYRk726QHfCxpBp5ZetIvcuIVOTmQBwemFHdXPnHLFVgXAtGKAtPokhWlYbx0bwzoXhFK5Dck1X9k7tdNIFp7wTfQtBu4 0Oi1oRpj qLU22+3GQPUiCma4YDiTHzCaEwhg0KbyQgrGK0pmggt+NZhtNDs25fKZtg7suIVjpQgrmPL1t1pglnABAIxYSvhFp6YXkVfyPmLx9g9+TWqiOjrEQVN97YTrDcD1h6xi/6e9J8nfDKL+wGQ1pvX5qHDQ6z5NfXxnLtuhFd2x0vlfhdZj4Q/C0y4Is/34WLErejqOGXk1c/6Jr4GCqAd1n3Uf9JwZsmzXN6SO2DbUBFz1SujSE6jrMhpyAySJKBu8Qp1wW/efq4XoKV3QoZZ6RnE5KF+1KYW+dyDtgKMTPFKQYFVye7Q6oIvwlx2yK3IoSxuBecQGcpXamqJ+JZ3MuerihvrPBZNje/xJL5mBagY/RN8QwzBVIHTghrJc7FFmCMXoGNrz7cx/XO5MbFiOX3CF5QgvfS2LSnRuL5VrGB7ipfXFmn5tPHTCinTEzNkg4xPlWVbSINZvjmasBJXaDzq189ALpViVKnChJ2859OmeogHlJWq6+crKS6w== 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, Apr 01, 2025 at 02:26:59PM +0200, Jens Wiklander wrote: > On Tue, Apr 1, 2025 at 12:13 PM 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? > > No, I don't think I have access to the needed documentation for the > board to set it up for relevant peripherals. > > > 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. > > A hypervisor in the normal world can also make the memory inaccessible > to the kernel. That shouldn't cause any hangups due to cache > speculation. The hypervisor should unmap the memory from EL2 translation tables which I think should disallow the cache speculation to take place. However, without hypervisor here the memory remains mapped in normal world which can lead to cache speculation for restricted buffers. That's why we should atleast test on one platform with real memory protection enabled to rule out any assumptions we make. -Sumit > > Cheers, > Jens > > > > > 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. > > > > [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reserved-memory/reserved-memory.yaml#L79 > > > > -Sumit