Hi Stefano,
Stefano Stabellini <[email protected]> writes: > On Mon, 6 Sep 2021, Oleksandr Tyshchenko wrote: >> From: Oleksandr Tyshchenko <[email protected]> >> >> 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 <[email protected]> >> Signed-off-by: Oleksandr Tyshchenko <[email protected]> >> Acked-by: Volodymyr Babchuk <[email protected]> > > 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
