On Wed, 4 May 2022, Volodymyr Babchuk wrote: > 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]>
committed with a small code syle fix
