On Mon, May 24, 2021, Jim Mattson wrote: > On Mon, May 24, 2021 at 3:28 PM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > That said, I'm not against switching to VMWRITE for everything, but regardless > > of which route we choose, we should commit to one or the other. I.e. double down > > on memset() and bet that Intel won't break KVM, or replace the memset() in > > alloc_vmcs_cpu() with a sequence that writes all known (possible?) fields. The > > current approach of zeroing the memory in software but initializing _some_ fields > > is the worst option, e.g. I highly doubt vmcs01 and vmcs02 do VMWRITE(..., 0) on > > the same fields. > > The memset should probably be dropped, unless it is there to prevent > information leakage. However, it is not necessary to VMWRITE all known > (or possible) fields--just those that aren't guarded by an enable bit. Yeah, I was thinking of defense-in-depth, e.g. better to have VM-Enter consume '0' than random garbage because KVM botched an enabling sequence. We essentially get that today via the memset(). I'll fiddle with the sequence and see how much overhead a paranoid and/or really paranoid approach would incur.
