>> 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
