On 2018年09月13日 21:00, Alexander Potapenko wrote:
Hi mighty virtio maintainers, I'm working on KMSAN, a new runtime detector of uninitialized memory based on compiler instrumentation (https://github.com/google/kmsan) KMSAN is mostly being tested on QEMU with KVM enabled, so my kernel interacts a lot with various virtio drivers, that's why I'm seeking your help. By default KMSAN treats kernel memory allocated by kmalloc() and alloc_page() as uninitialized. Writing a constant to memory or using it in copy_from_user() makes that memory initialized. Unfortunately a lot of writes to memory from KVM (mostly in the disk and network drivers) remain unnoticed by the tool, therefore we're seeing a lot of false positive reports (along with actual bugs, like CVE-2018-1118). KMSAN has an API function `kmsan_unpoison_shadow(void *buf, int len)`, which means "from now on, till this memory is freed or written to, mark it as initialized". I've tried playing Whack-a-Mole adding it to various places where the data comes from KVM, but failed to find them all. In fact, some of my annotations were wrong, so I ended up with the following two patches: https://github.com/google/kmsan/commit/76c671199a4de5bbe73cd13210a5e28848211bd1 https://github.com/google/kmsan/commit/40ba1c8e2a3c6bbe8f34037413e253894251a405 But I'm far from being sure this is the complete list of places where the memory is initialized by virtio drivers. May I ask you to help me find the places where we actually need to annotate the memory in virtio?
It looks to me another one is the used ring which device writes back the completed descriptor id and length. It (vr->used) was a part of a page which was allocated in vring_alloc_queue() through alloc_pages_exact() with __GFP_ZERO. So I'm not we need care about it.
Thanks
Thanks in advance,
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
