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

[Oleksandr <olekstysh@xxxxxxxxx>]

Hello all


Gentle reminder.


On 23.09.21 23:57, Volodymyr Babchuk wrote:
> 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.
--
Regards,

Oleksandr Tyshchenko