linux

iv/linux

History

Robin Murphy 4a37f3dd9a dma-direct: don't over-decrypt memory

The original x86 sev_alloc() only called set_memory_decrypted() on
memory returned by alloc_pages_node(), so the page order calculation
fell out of that logic. However, the common dma-direct code has several
potential allocators, not all of which are guaranteed to round up the
underlying allocation to a power-of-two size, so carrying over that
calculation for the encryption/decryption size was a mistake. Fix it by
rounding to a *number* of pages, rather than an order.

Until recently there was an even worse interaction with DMA_DIRECT_REMAP
where we could have ended up decrypting part of the next adjacent
vmalloc area, only averted by no architecture actually supporting both
configs at once. Don't ask how I found that one out...

Fixes: c10f07aa27da ("dma/direct: Handle force decryption for DMA coherent buffers in common code")
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: David Rientjes <rientjes@google.com>

2022-05-23 15:25:40 +02:00

coherent.c

dma-mapping: use 'bitmap_zalloc()' when applicable

2021-10-27 08:20:09 +02:00

contiguous.c

cma: factor out minimum alignment requirement

2022-03-22 15:57:05 -07:00

debug.c

dma-debug: change allocation mode from GFP_NOWAIT to GFP_ATIOMIC

2022-05-11 19:48:34 +02:00

debug.h

dma-debug: teach add_dma_entry() about DMA_ATTR_SKIP_CPU_SYNC