On Wed, 2023-10-18 at 18:42 +0100, Robin Murphy wrote: > On 2023-10-17 21:25, Rick Edgecombe wrote: > > On TDX it is possible for the untrusted host to cause > > set_memory_encrypted() or set_memory_decrypted() to fail such that > > an > > error is returned and the resulting memory is shared. Callers need > > to take > > care to handle these errors to avoid returning decrypted (shared) > > memory to > > the page allocator, which could lead to functional or security > > issues. > > > > DMA could free decrypted/shared pages if set_memory_decrypted() > > fails. > > Use the recently added free_decrypted_pages() to avoid this. > > > > Several paths also result in proper encrypted pages being freed > > through > > the same freeing function. Rely on free_decrypted_pages() to not > > leak the > > memory in these cases. > > If something's needed in the fallback path here, what about the > cma_release() paths? You mean inside cma_release(). If so, unfortunately I think it won't fit great because there are callers that are never dealing with shared memory (huge tlb). The reset-to-private operation does extra work that would be nice to avoid when possible. The cases I thought exhibited the issue were the two calls sites of dma_set_decrypted(). Playing around with it, I was thinking it might be easier to just fix those to open code leaking the pages on dma_set_decrypted() error. In which case it won't have the re-encrypt problem. It make's it less fool proof, but more efficient. And free_decrypted_pages() doesn't fit great anyway, as pointed out by Christoph.
