On Wed, Oct 30, 2019 at 3:38 PM Christoph Hellwig <hch@xxxxxx> wrote:
>
> On Wed, Oct 30, 2019 at 03:22:34PM +0100, glider@xxxxxxxxxx wrote:
> > When data is copied to memory from a device KMSAN should treat it as
> > initialized. In most cases it's enough to just unpoison the buffer that
> > is known to come from a device.
> > In the case with __do_page_cache_readahead() and bio_copy_user_iov() we
> > have to mark the whole pages as ignored by KMSAN, as it's not obvious
> > where these pages are read again.
>
> A lot of this looks pretty strange. Why don't you instrument
> the dma_map / dma_sync infrastucture? That should avoid most of the
> driver hooks.
That's the exact reason I'm sending these patches: I simply don't know
the kernel code good enough.
May I ask you for some pointers?
My goal is to mark data copied from the device as initialized (by
calling kmsan_unpoison_shadow(ptr, size)), and, if possible, check
data that's about to be copied to device (by calling
kmsan_check_memory(ptr, size)).
My understanding is that:
1. calls to dma_map_* and dma_sync_* with direction=DMA_FROM_DEVICE
denote that the corresponding kernel buffer can be marked as
initialized
2. calls to dma_unmap_* and dma_sync_* with direction=DMA_TO_DEVICE
denote that the buffer will be copied to device (and must be checked
for being initialized)
3. I need some translation table to find out the virtual address for
a given dma_addr_t
Does this sound reasonable?
I still don't understand how to handle DMA_BIDIRECTIONAL. Will it be
sane to assume that at each dma_{map,sync,unmap}_* call must always
check the memory range and then unpoison it?
Thanks in advance
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
