Hello Jens,

Jens Wiklander <[email protected]> writes:

> This commit fixes a case overlooked in [1].
>
> There are two kinds of shared memory buffers used by OP-TEE:
> 1. Normal payload buffer
> 2. Internal command structure buffers
>
> The internal command structure buffers are represented with a shadow
> copy internally in Xen since this buffer can contain physical addresses
> that may need to be translated between real physical address and guest
> physical address without leaking information to the guest.
>
> [1] fixes the problem when releasing the normal payload buffers. The
> internal command structure buffers must be released in the same way.
> Failure to follow this order opens a window where the guest has freed
> the shared memory but Xen is still tracking the buffer.
>
> During this window the guest may happen to recycle this particular
> shared memory in some other thread and try to use it. Xen will block
> this which will lead to spurious failures to register a new shared
> memory block.
>
> Fix this by freeing the internal command structure buffers first before
> informing the guest that the buffer can be freed.
>
> [1] 5b13eb1d978e ("optee: immediately free buffers that are released by 
> OP-TEE")
>
> Signed-off-by: Jens Wiklander <[email protected]>

Thank you for the fix:

Reviewed-by: Volodymyr Babchuk <[email protected]>


-- 
Volodymyr Babchuk at EPAM

Reply via email to