[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] xen/arm: optee: Allocate anonymous domheap pages

  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Date: Thu, 23 Sep 2021 20:57:45 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=33YY/lzY/yKZw2ugpJeA/6jj2dtPeDssOR+MbSG/TjU=; b=S0LhuYmqkuxEA1GpwI2uykHWAuIMFAE7coutXM3DMcdtVz7ra8hzxWXZ4odqVKOzCYE65zJY31v5USPKcTmYm7Ri5PTULbjMYvZbRHWi401GdpXr833Tcwpbph+wokbxQ5GtB5bGGwaH/UlDjSaSnq6e1PXaTJMrAp6k/UNWpD6sQUSkq+cULbjg2rljnDTu0W2yoWaNSHq6/KI4PD++VVUgIEKrpnitfK2LPhQXq7almm9FTH5U+xnJK+JtvJQYj58qwpzPg0YLr8VTMsSK1szk5P24NUslTW77A2Ggqi3jb65vAahQkdiEJcEeh+AVsUqNcMVo5TJG8ddwA3hYTA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NXCymN6coiIwm/KNaWGODnzmA/OjGooOMRbOKRU2uzLnavdeBsPIvhsf+c8d7Lr6h9N2tAhRPGAmR8TvV8UCAC7vag4vPcBcyNWSEnv57pz3XfiN1ee7vdIEP64MltFYeXaObAxfSVaGXAyX51urXxB+tcU1O9Qpul7QsLvlpSI4zQ7UoM4YBx9FZhuU/e+Ydfx9nSaLvYEg1LcaQgNep3UaXUWbviVmJ7OpJraKCLgt13LZSIYvYydCuWWYiYZpSK1iPryeXJhRXWHfvJwfZHoIphUnoIGYnQHqSY+/hYg0zrmhwMkOsVEGQ2MasGx02wltdnsY8DlnBFio45WBhw==
  • Authentication-results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=epam.com;
  • Cc: Oleksandr Tyshchenko <olekstysh@xxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Julien Grall <jgrall@xxxxxxxxxx>
  • Delivery-date: Thu, 23 Sep 2021 20:57:56 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHXoyUNSkY32SPluU6N5DMbFmm656uyJ0MAgAAJFoA=
  • Thread-topic: [PATCH] xen/arm: optee: Allocate anonymous domheap pages

Hi Stefano,

Stefano Stabellini <sstabellini@xxxxxxxxxx> writes:

> On Mon, 6 Sep 2021, Oleksandr Tyshchenko wrote:
>> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
>> Allocate anonymous domheap pages as there is no strict need to
>> account them to a particular domain.
>> Since XSA-383 "xen/arm: Restrict the amount of memory that dom0less
>> domU and dom0 can allocate" the dom0 cannot allocate memory outside
>> of the pre-allocated region. This means if we try to allocate
>> non-anonymous page to be accounted to dom0 we will get an
>> over-allocation issue when assigning that page to the domain.
>> The anonymous page, in turn, is not assigned to any domain.
>> CC: Julien Grall <jgrall@xxxxxxxxxx>
>> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
>> Acked-by: Volodymyr Babchuk <volodymyr_babchuk@xxxxxxxx>
> Only one question, which is more architectural: given that these pages
> are "unlimited", could the guest exploit the interface somehow to force
> Xen to allocate an very high number of anonymous pages?
> E.g. could a domain call OPTEE_SMC_RPC_FUNC_ALLOC in a loop to force Xen
> to exaust all memory pages?

Generally, OP-TEE mediator tracks all resources allocated and imposes
limits on them.

OPTEE_SMC_RPC_FUNC_ALLOC case is a bit different, because it is issued
not by domain, but by OP-TEE itself. As OP-TEE is more trusted piece of
system we allow it to request as many buffers as it wants. Also, we know
that OP-TEE asks only for one such buffer per every standard call. And
number of simultaneous calls is limited by number of OP-TEE threads,
which is quite low: typically only two.

Volodymyr Babchuk at EPAM



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.