linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: "Xiaoming Ding (丁晓明)" <Xiaoming.Ding@mediatek.com>,
	"hch@infradead.org" <hch@infradead.org>,
	"sumit.garg@linaro.org" <sumit.garg@linaro.org>
Cc: "Fei Xu (徐飞)" <Fei.Xu@mediatek.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"srv_heupstream@mediatek.com" <srv_heupstream@mediatek.com>,
	"jens.wiklander@linaro.org" <jens.wiklander@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"op-tee@lists.trustedfirmware.org"
	<op-tee@lists.trustedfirmware.org>,
	"matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
	"angelogioacchino.delregno@collabora.com"
	<angelogioacchino.delregno@collabora.com>
Subject: Re: [PATCH] tee: add FOLL_LONGTERM for CMA case when alloc shm
Date: Fri, 19 May 2023 12:01:21 +0200	[thread overview]
Message-ID: <83a846a9-8f88-3f66-b840-e84d072bb0fb@redhat.com> (raw)
In-Reply-To: <781d993204fbbdf30a6ca495b59b3b0aa7a2e496.camel@mediatek.com>

On 18.05.23 08:40, Xiaoming Ding (丁晓明) wrote:
>  From 35fd062d5cbc4d182eee0183843cd6350d126788 Mon Sep 17 00:00:00 2001
> From: Xiaoming Ding <xiaoming.ding@mediatek.com>
> Date: Wed, 10 May 2023 10:15:23 +0800
> Subject: [PATCH v2] tee: add FOLL_LONGTERM for CMA case when alloc shm
> 
> CMA is widely used on insufficient memory platform for
> secure media playback case, and FOLL_LONGTERM will
> avoid tee_shm alloc pages from CMA region.
> without FOLL_LONGTERM, CMA region may alloc failed since
> tee_shm has a chance to use it in advance.
> 
> modify is verified on OPTEE XTEST and kinds of secure + clear playback
> 
> 
> Fixes: 033ddf12bcf5 ("tee: add register user memory")
> Signed-off-by: Xiaoming Ding <xiaoming.ding@mediatek.com>
> ---
> v1 -> v2: take off the ifdef and apply FOLL_LONGTERM by default
> 
>   drivers/tee/tee_shm.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
> index 673cf0359494..38878e549ca4 100644
> --- a/drivers/tee/tee_shm.c
> +++ b/drivers/tee/tee_shm.c
> @@ -257,7 +257,7 @@ register_shm_helper(struct tee_context *ctx,
> unsigned long addr,
>   	}
>   
>   	if (flags & TEE_SHM_USER_MAPPED)
> -		rc = pin_user_pages_fast(start, num_pages, FOLL_WRITE,
> +		rc = pin_user_pages_fast(start, num_pages, FOLL_WRITE |
> FOLL_LONGTERM,
>   					 shm->pages);
>   	else
>   		rc = shm_get_kernel_pages(start, num_pages, shm-
>> pages);

I didn't dive deeply into that code, but I can spot that we can end up 
long-term pinning multiple pages -- possibly unbound or is there any 
sane limit on the number of pages?

Take a look at io_uring/rsrc.c and how we account long-term pinned pages 
against user->locked_vm/ctx->mm_account->pinned_vm in io_account_mem().

If user space could only end up pinning one or two pages via that 
interface, ok. But it looks like this interface could be abused to 
create real real trouble by unprivileged users that should be able to 
long-term pin that many pages.

Am I missing something important (i.e., interface is only accessible by 
privileged users) or should there be proper accounting and 
RLIMIT_MEMLOCK checks?

-- 
Thanks,

David / dhildenb



  reply	other threads:[~2023-05-19 10:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20230517031856.19660-1-xiaoming.ding@mediatek.com>
2023-05-17  7:34 ` Christoph Hellwig
2023-05-17  7:52   ` Sumit Garg
2023-05-17  8:08     ` Christoph Hellwig
2023-05-17  9:02       ` Xiaoming Ding (丁晓明)
2023-05-17  9:26       ` Sumit Garg
2023-05-17  9:36         ` Christoph Hellwig
2023-05-17 10:19           ` Sumit Garg
2023-05-17 18:23             ` David Hildenbrand
2023-05-18  4:20               ` FOLL_LONGTERM vs FOLL_EPHEMERAL " Christoph Hellwig
2023-05-18  6:08                 ` Sumit Garg
2023-05-18 13:56                   ` David Hildenbrand
2023-05-23  1:54                     ` John Hubbard
2023-05-23  7:25                       ` Lorenzo Stoakes
2023-06-13  5:30                         ` Xiaoming Ding (丁晓明)
2023-06-13  8:48                           ` Sumit Garg
2023-05-18  6:40             ` Xiaoming Ding (丁晓明)
2023-05-19 10:01               ` David Hildenbrand [this message]
2023-05-19 11:03                 ` Sumit Garg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83a846a9-8f88-3f66-b840-e84d072bb0fb@redhat.com \
    --to=david@redhat.com \
    --cc=Fei.Xu@mediatek.com \
    --cc=Xiaoming.Ding@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=hch@infradead.org \
    --cc=jens.wiklander@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=matthias.bgg@gmail.com \
    --cc=op-tee@lists.trustedfirmware.org \
    --cc=srv_heupstream@mediatek.com \
    --cc=sumit.garg@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox