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 90B90C369A5 for ; Tue, 8 Apr 2025 13:39:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C597B6B0008; Tue, 8 Apr 2025 09:39:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BDE9F6B000A; Tue, 8 Apr 2025 09:39:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A80E16B000C; Tue, 8 Apr 2025 09:39:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8AA846B0008 for ; Tue, 8 Apr 2025 09:39:46 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 81779ADE8F for ; Tue, 8 Apr 2025 13:39:48 +0000 (UTC) X-FDA: 83310984456.11.161B62D Received: from mail-oa1-f52.google.com (mail-oa1-f52.google.com [209.85.160.52]) by imf01.hostedemail.com (Postfix) with ESMTP id 8C86C40014 for ; Tue, 8 Apr 2025 13:39:46 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=zXfnDSzw; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf01.hostedemail.com: domain of jens.wiklander@linaro.org designates 209.85.160.52 as permitted sender) smtp.mailfrom=jens.wiklander@linaro.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744119586; 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=KHOdC/Vml2+FnzmLfGzflP63fCypDI+MruYpwHo3lNA=; b=OMZfOw/DjSyv22AUkit0A+LVSp8isVyRWKRN/FDgSUSXgfUhTfu5wnz2DOdtjcsbArzO3i V3exX8bQzK9aBGRmhrEaz18Beuy4b1+QDtEr6KcK0NN9ZADvWMr/XYoOsjpZ+KrMNBHR6S HnuIUxOsq+sa7h+K1foril7xEbp+2g8= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=linaro.org header.s=google header.b=zXfnDSzw; dmarc=pass (policy=none) header.from=linaro.org; spf=pass (imf01.hostedemail.com: domain of jens.wiklander@linaro.org designates 209.85.160.52 as permitted sender) smtp.mailfrom=jens.wiklander@linaro.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744119586; a=rsa-sha256; cv=none; b=5AOXj1FUshbQVV84JLK7u6o24noHFcgqAXiItedBOnWIXw+k/RQ7dpcfJLWyV9d/e3FrS9 Bt605KgzpK7bkt/pYry/6x6z4Sqk7iLvK21kwvM37LdtvI0HAbqHJWmGFr0xD6YN1KyNHY 6IkBjZd+X+sq+5g0/DRgG79jv4lNtuM= Received: by mail-oa1-f52.google.com with SMTP id 586e51a60fabf-2cca475546fso2172203fac.1 for ; Tue, 08 Apr 2025 06:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1744119585; x=1744724385; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KHOdC/Vml2+FnzmLfGzflP63fCypDI+MruYpwHo3lNA=; b=zXfnDSzwMJpKQzAy7FV61A4ARnlf0q0Vw8a/++7eLRlzsJSGITM3UyQLwguk2LjnkF EHhC/co27k9YZQ+xmPovluAWidkvr9IHNKFzHURUXRuR62Uk2f7zGF2O6iIJykJEZo/O IcQjk+/sn59VD0kf3YELR3wKiJXXJQYuaokPioXavFGUipyPZFbAlsgyzOvkcSQQUX+N pybSOOA3fBWG9LZq8h+3Zv9jFx1J0QyzqTeOknyEk4zlk6LGzMW58CEihs/hmqdaLpmH RdVdMrNF7xTRb2QDqiNBoBSaMq++2JWrko26eeh/QqSzO5CdIlUzlI+G1cWVSFFhNS3h V12g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1744119585; x=1744724385; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KHOdC/Vml2+FnzmLfGzflP63fCypDI+MruYpwHo3lNA=; b=SeM2OnGh+InISOXQltbXTBfQpDla4LAjfnInh+C/MhkNXAACn/Wm6ArJIODkDlVydj UpubjGHnx1wWO8i85Ifpeddecg6R3eMG7Tvw8/Y/E80BskNpnOo7ARqgjKlNFAmRB3kW 9DRy71sWg9xSHUjpesIeyChBRpOIjcB8E/lAcbPjMt+IjvyVY2gegaWFJwtFMmjmNrSN WA1eFHKfiezyB8vF9UtfV9maLfJfevWokdZAS46+NzkZSToPGcfBVALvc962iDR6/V8G YrhepOTpTErZjdQjeNP4FZcN2w8ceYqtkYF2H1rjpPkfR1LOAlSobk04J4VVQaLuyZx4 DLVg== X-Forwarded-Encrypted: i=1; AJvYcCWpXsbGklMExg/XDez+v1fNaTTGFWcr8bicnBPqwLcjdurs81W6KfmpQNJkIiQIxs4BohcZJDM7kA==@kvack.org X-Gm-Message-State: AOJu0Yz745SeWJbf8PWIoGk0bjKwHUmlZd4rArSFtbmp0M+xqaW8ZVCO 0Euh8GK09LV6VT59HVuKxq3y9vF7Xo6ZKS52yOiGx6k3RnTuOgWy/uaAG6C7/et5eHAsLwsPF6y oS2hHT1RjgQusQezpRyDHAc0fEYr1zKXfijc/Bg== X-Gm-Gg: ASbGnctCDmBUjLOUN78CiWGrNpkzPJZwH5PNdt7y3x2IcgwzRfMA9QwZCf5uSwlx3sa 0rJzD5yLa6HDmpbHcXWnrqzckbFv2D9x+aGWbzTPrCuHER+LaOcBB36v6l71a1TGC1xXLtAKK54 S9BW0XsdyZniBLd0qw9CWc/crBEaI= X-Google-Smtp-Source: AGHT+IFDzPIFIE+uzUvKzwMFVIPM56PzO88jEFUON9fAPcL/eNFR02o6bcfZi6WAQ34EoSMSHnDr8Fk6F3d560XOiCg= X-Received: by 2002:a05:6870:2b10:b0:295:eb96:9fd4 with SMTP id 586e51a60fabf-2cc9e59d03amr9326894fac.11.1744119585123; Tue, 08 Apr 2025 06:39:45 -0700 (PDT) MIME-Version: 1.0 References: <20250305130634.1850178-1-jens.wiklander@linaro.org> <20250305130634.1850178-10-jens.wiklander@linaro.org> In-Reply-To: From: Jens Wiklander Date: Tue, 8 Apr 2025 15:39:33 +0200 X-Gm-Features: ATxdqUFlhhnGRONqCMm9Feg_Wns0J0dqc4_QCcuIsEY1x6VIJsUuiFEXYdjvaKs Message-ID: Subject: Re: [PATCH v6 09/10] optee: FF-A: dynamic restricted memory allocation To: Sumit Garg 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" , =?UTF-8?Q?Christian_K=C3=B6nig?= , Matthias Brugger , AngeloGioacchino Del Regno , azarrabi@qti.qualcomm.com, Simona Vetter , Daniel Stone , linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 8C86C40014 X-Stat-Signature: ycho4gctkjtab5ts51d6zib9coxxawq6 X-Rspam-User: X-HE-Tag: 1744119586-587105 X-HE-Meta: U2FsdGVkX1+1UnPqjWULc3jm6z/5Xpv+C2Nzi5Nv5NntTkdWYD1ZhPQVv3dwfzxWlb5icNCH+r/ktj9PCiXkUbCti5E3V7gg4Nsr/lLhRxfeUJBpoo8odjgJxYXJoTRNBGDxlMfrAaVJLOdwo4xs8RmMJGd+uMZnwTIm6AB8+b4CJgUARoObwb06HdEuI0Z6cjaBLrhPusBQSGt62Ktce5/D32Aiyq6YX6bbYx6mFtAhsqnjbiaeifv1xqRg2C6OBQjvtWFHKlNXtDxq9q8GkO1B0csulUEKIcSNCAKjoYiqjnEeeCtvEkhltQQvhHM9V6zb4d9E9lC0l0rMSaIiwI6apXt64T/4Gv0d93fqvg+OaqcBQBzpt5LqGcCxgHyxl+OD0zWca8ELPxuYIGr+liwpEcGvcF98f2Nhfi+gCC7Uq0K6f0H3jNjG4B+hO/lGVvRlvodUkIo96+f3QnAZOHoXTa2UZwIurkRR7GWM+BLCLexatG+qRsdz2SY9gpkoTc1x8lkgPjCC/jJN4UlzBRypYA/KHMyJMiAe9MZ0QVMZ2kUsqhxds0sEnEHU9WEiFuz+BM5Qh9BpA3u+rlnoS9iSivP1s1R2e0ofY6oudPefTp6nCJ+xkOv+LQkAFCFk6Hd71ZD5TIUunVMTS/0hhuKh7FlkzdQI5Jsp+jCbGaeqLEK4DSA3mQwbbKFAmIVowUBDucGVfV2dvr373HwJpXpLthEbV+ndrv2W9JfQ2cYvOjhYPURP4WzmJtFySACN+s3d+k/Jp/xQiScFulCojNsCM0s6NR6cd8R8B7j9ZMCXqi6G70Qo5hLU1vDPg6rUT5mub1+BxRCexgq3jbofXrcQkfhulAvK6kJTgp6paBrnw0FiHcTK3ButkNMlaYuXV1imXJcv/yMQI0saCc5r8Zv2gXzRr9RqotnynW+paRyYTRf20cy4HNbTRlY3ROSiLw76rb8faKCr73CYzmI ygbAN1pd Ae92YlQb5IRuBMlLawRtMve8bEUXQP0ClC+wAY55AuMzx1Cvu1Mej9W8GwujppTv++xi4MsS8O2y8qsn9nB4itoDgsSb7J/0X0b2c2GYPlki10MZZUCCnElfrMhJU5CJtlgZ44LTrC9f/AtN14oSJII+FbxgZQdxlc0HvsANzLUMyoesPpTJQH7SutUIisbuxZw6MDObARbMSlDVx3p78JE1dKKn8j3wJS1USpC0C6q5lQKuP7f/zhK0QywCTag61gdZqf7KSBWXYt6et9Yg3YoMxrYZBFld4yDg/5HREteuclRDTEnBd6o9O/sJb+HWgfxrvpqqfZsgSNOcLfUNgaVwT2/4ewmOKXlgtnTGc6lt4yiM= 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 8, 2025 at 11:20=E2=80=AFAM Sumit Garg = wrote: > > On Tue, Apr 01, 2025 at 02:26:59PM +0200, Jens Wiklander wrote: > > On Tue, Apr 1, 2025 at 12:13=E2=80=AFPM 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=E2=80=AFAM 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 mem= ory > > > > > > allocation with FF-A. > > > > > > > > > > > > The restricted memory pools for dynamically allocated restrict = memory > > > > > > are instantiated when requested by user-space. This instantiati= on can > > > > > > fail if OP-TEE doesn't support the requested use-case of restri= cted > > > > > > memory. > > > > > > > > > > > > Restricted memory pools based on a static carveout or dynamic a= llocation > > > > > > can coexist for different use-cases. We use only dynamic alloca= tion 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/rst= mem.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 struc= t */ > > > > > > + 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, p= ool); > > > > > > +} > > > > > > + > > > > > > +static int init_cma_rstmem(struct optee_rstmem_cma_pool *rp) > > > > > > +{ > > > > > > + int rc; > > > > > > + > > > > > > + rp->rstmem =3D tee_shm_alloc_cma_phys_mem(rp->optee->ctx,= rp->page_count, > > > > > > + rp->align); > > > > > > + if (IS_ERR(rp->rstmem)) { > > > > > > + rc =3D 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 h= ere > > > > > which can allocate un-mapped memory such that any cache speculati= on > > > > > won't lead to CPU hangs once the memory restriction comes into pi= cture. > > > > > > > > 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 explic= it > > > 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. Do I hear a volunteer? ;-) Anyway, this isn't something that can be enabled in the kernel alone. Only platforms where the firmware has been updated will be affected. If this can't be supported on a particular platform, there's still the option with a static carveout. Cheers, Jens > > -Sumit > > > > > Cheers, > > Jens > > > > > > > > MM folks, > > > > > > Basically what we are trying to achieve here is a "no-map" DT behavio= ur > > > [1] which is rather dynamic in nature. The use-case here is that a m= emory > > > 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 A= PIs > > > to use for un-mapping/mamping CMA allocations for this use-case. > > > > > > [1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/sc= hemas/reserved-memory/reserved-memory.yaml#L79 > > > > > > -Sumit