Re: [PATCH v10 16/41] KVM: guest_memfd: Zero page while getting pfn
"David Hildenbrand (Arm)" <[email protected]>
| Newsgroups | dev.linux.lists.linux-coco,org.kernel.vger.kvm,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-trace-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
>> Previously, without in-place conversion, populate never reads memory >> from guest_memfd so there was no danger of leaking uninitialized memory. >>> >>> In case post-populate failed, do we want to re-zero the pages? >> >> I believe we can't re-zero the pages. When SNP fails to populate it >> could be because SNP didn't like the CPUIDs userspace set up, and after >> the error userspace is expected to check what SNP likes, then >> retry. Ah, okay. >> >> IIUC zeroing will destroy the message SNP wanted to leave for userspace. >> >> Michael should be able to explain more here :) > > Not Michael, but the above is correct. If firmware rejects a CPUID page, then > KVM copies back the expected CPUID values provided by firmware. > > That said, now that we have have @may_writeback_src we _could_ re-zero the page, > i.e. only zero pages for which @may_writeback_src is %false. > > And _that_ said, I vote "no". KVM zeros the memory mostly to ensure userspace > can't read stale data, e.g. someone else's data. I don't think we need to > guarantee that a failed populate() (or rather, whatever ioctl called into it) > will leave memory in any particular state. It would be easier to document that > the page contents may be modified on failure. Let's do that then! -- Cheers, David