Messages in this thread | | | From | Vitaly Kuznetsov <> | Subject | Re: [PATCH] KVM: x86: work around leak of uninitialized stack contents | Date | Thu, 12 Sep 2019 18:44:21 +0200 |
| |
Jim Mattson <jmattson@google.com> writes:
> On Thu, Sep 12, 2019 at 1:51 AM Vitaly Kuznetsov <vkuznets@redhat.com> wrote: >> >> Fuqian Huang <huangfq.daxian@gmail.com> writes: >> >> > Emulation of VMPTRST can incorrectly inject a page fault >> > when passed an operand that points to an MMIO address. >> > The page fault will use uninitialized kernel stack memory >> > as the CR2 and error code. >> > >> > The right behavior would be to abort the VM with a KVM_EXIT_INTERNAL_ERROR >> > exit to userspace; >> >> Hm, why so? KVM_EXIT_INTERNAL_ERROR is basically an error in KVM, this >> is not a proper reaction to a userspace-induced condition (or ever). > > This *is* an error in KVM. KVM should properly emulate the quadword > store to the emulated device. Doing anything else is just wrong. > > KVM_INTERNAL_ERROR is basically a cop-out for things that are hard.
Yes, I way arguing with "the right behavior would be" in relation to KVM_INTERNAL_ERROR.
> >> I also looked at VMPTRST's description in Intel's manual and I can't >> find and explicit limitation like "this must be normal memory". We're >> just supposed to inject #PF "If a page fault occurs in accessing the >> memory destination operand." >> >> In case it seems to be too cumbersome to handle VMPTRST to MMIO and we >> think that nobody should be doing that I'd rather prefer injecting #GP. > > That is not the architected behavior at all. Now you're just making > things up!
True and I'm not against KVM_INTERNAL_ERROR as an iterim solution if it comes with a comment explaining why we're 'admitting defeat' here.
-- Vitaly
| |