From: Vitaly Kuznetsov <vkuznets@redhat.com>
To: Jim Mattson <jmattson@google.com>
Cc: "Fuqian Huang" <huangfq.daxian@gmail.com>,
"Paolo Bonzini" <pbonzini@redhat.com>,
"Radim Krčmář" <rkrcmar@redhat.com>,
"Sean Christopherson" <sean.j.christopherson@intel.com>,
"Wanpeng Li" <wanpengli@tencent.com>,
"Joerg Roedel" <joro@8bytes.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Borislav Petkov" <bp@alien8.de>,
"H . Peter Anvin" <hpa@zytor.com>,
"the arch/x86 maintainers" <x86@kernel.org>,
"kvm list" <kvm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] KVM: x86: work around leak of uninitialized stack contents
Date: Thu, 12 Sep 2019 18:44:21 +0200 [thread overview]
Message-ID: <874l1hcvmi.fsf@vitty.brq.redhat.com> (raw)
In-Reply-To: <CALMp9eRu=C+MQmRpKh5WtyqBKq=ja8Wj7fD5NTFhZi9EZd+84w@mail.gmail.com>
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
next prev parent reply other threads:[~2019-09-12 16:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-12 4:18 [PATCH] KVM: x86: work around leak of uninitialized stack contents Fuqian Huang
2019-09-12 8:51 ` Vitaly Kuznetsov
2019-09-12 8:56 ` Fuqian Huang
2019-09-12 10:53 ` Vitaly Kuznetsov
2019-09-12 12:02 ` Fuqian Huang
2019-09-12 16:20 ` Jim Mattson
2019-09-12 16:44 ` Vitaly Kuznetsov [this message]
2019-09-12 21:20 ` Jim Mattson
2019-09-12 23:52 ` Sean Christopherson
2019-09-13 9:07 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874l1hcvmi.fsf@vitty.brq.redhat.com \
--to=vkuznets@redhat.com \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=huangfq.daxian@gmail.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=rkrcmar@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=tglx@linutronix.de \
--cc=wanpengli@tencent.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.