From: Sean Christopherson <seanjc@google.com>
To: Binbin Wu <binbin.wu@linux.intel.com>
Cc: Kai Huang <kai.huang@intel.com>,
"yuan.yao@linux.intel.com" <yuan.yao@linux.intel.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
Xiaoyao Li <xiaoyao.li@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Isaku Yamahata <isaku.yamahata@intel.com>
Subject: Re: [PATCH v3 1/2] KVM: x86: Check hypercall's exit to userspace generically
Date: Fri, 1 Nov 2024 08:26:44 -0700 [thread overview]
Message-ID: <ZyTzNHil-55v7D3r@google.com> (raw)
In-Reply-To: <9c55087b-e529-46cd-8678-51975a9acc71@linux.intel.com>
On Fri, Nov 01, 2024, Binbin Wu wrote:
> On 10/31/2024 10:54 PM, Sean Christopherson wrote:
> > My other idea was have an out-param to separate the return code intended for KVM
> > from the return code intended for the guest. I generally dislike out-params, but
> > trying to juggle a return value that multiplexes guest and host values seems like
> > an even worse idea.
> >
> > Also completely untested...
...
> > case KVM_HC_MAP_GPA_RANGE: {
> > u64 gpa = a0, npages = a1, attrs = a2;
> > - ret = -KVM_ENOSYS;
> > + *ret = -KVM_ENOSYS;
> > if (!user_exit_on_hypercall(vcpu->kvm, KVM_HC_MAP_GPA_RANGE))
> > break;
> > if (!PAGE_ALIGNED(gpa) || !npages ||
> > gpa_to_gfn(gpa) + npages <= gpa_to_gfn(gpa)) {
> > - ret = -KVM_EINVAL;
> > + *ret = -KVM_EINVAL;
> > break;
> > }
>
> *ret needs to be set to 0 for this case before returning 0 to caller?
No, because the caller should consume *ret if and only if the function return value
is '1', i.e. iff KVM should resume the guest. And I think we actually want to
intentionally not touch *ret, because a sufficient smart compiler (or static
analysis tool) should be able to detect that incorrect usage of *ret is consuming
uninitialized data.
> > @@ -10080,13 +10078,13 @@ unsigned long __kvm_emulate_hypercall(struct kvm_vcpu *vcpu, unsigned long nr,
> > return 0;
> > }
> > default:
> > - ret = -KVM_ENOSYS;
> > + *ret = -KVM_ENOSYS;
> > break;
> > }
> > out:
> > ++vcpu->stat.hypercalls;
> > - return ret;
> > + return 1;
> > }
> > EXPORT_SYMBOL_GPL(__kvm_emulate_hypercall);
> > @@ -10094,7 +10092,7 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
> > {
> > unsigned long nr, a0, a1, a2, a3, ret;
> > int op_64_bit;
> > - int cpl;
> > + int cpl, r;
> > if (kvm_xen_hypercall_enabled(vcpu->kvm))
> > return kvm_xen_hypercall(vcpu);
> > @@ -10110,10 +10108,9 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
> > op_64_bit = is_64_bit_hypercall(vcpu);
> > cpl = kvm_x86_call(get_cpl)(vcpu);
> > - ret = __kvm_emulate_hypercall(vcpu, nr, a0, a1, a2, a3, op_64_bit, cpl);
> > - if (nr == KVM_HC_MAP_GPA_RANGE && !ret)
> > - /* MAP_GPA tosses the request to the user space. */
> > - return 0;
> > + r = __kvm_emulate_hypercall(vcpu, nr, a0, a1, a2, a3, op_64_bit, cpl, &ret);
> > + if (r <= r)
> A typo here.
> I guess it meant to be "if (r <= ret)" ?
No, "if (r <= 0)", i.e. exit to userspace on 0 or -errno.
> So the combinations will be
> ----------------------------------------------------------------------------
> | r | ret | r <= ret |
> ---|-----|-----------|----------|-------------------------------------------
> 1 | 0 | 0 | true | return r, which is 0, exit to userspace
> ---|-----|-----------|----------|-------------------------------------------
> 2 | 1 | 0 | false | set vcpu's RAX and return back to guest
> ---|-----|-----------|----------|-------------------------------------------
> 3 | 1 | -KVM_Exxx | false | set vcpu's RAX and return back to guest
> ---|-----|-----------|----------|-------------------------------------------
> 4 | 1 | Positive | true | return r, which is 1,
> | | N | | back to guest without setting vcpu's RAX
> ----------------------------------------------------------------------------
>
> KVM_HC_SEND_IPI, which calls kvm_pv_send_ipi() can hit case 4, which will
> return back to guest without setting RAX. It is different from the current behavior.
>
> r can be 0 only if there is no other error detected during pre-checks.
> I think it can just check whether r is 0 or not.
Yeah, I just fat fingered the code (and didn't even compile test).
next prev parent reply other threads:[~2024-11-01 15:26 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-26 2:22 [PATCH v3 0/2] KVM: x86: Check hypercall's exit to userspace generically Binbin Wu
2024-08-26 2:22 ` [PATCH v3 1/2] " Binbin Wu
2024-10-09 6:48 ` Xiaoyao Li
2024-10-30 20:49 ` Sean Christopherson
2024-10-31 0:49 ` Huang, Kai
2024-10-31 14:54 ` Sean Christopherson
2024-11-01 2:25 ` Binbin Wu
2024-11-01 15:26 ` Sean Christopherson [this message]
2024-11-01 11:05 ` Huang, Kai
2024-11-01 16:39 ` Sean Christopherson
2024-11-01 21:13 ` Huang, Kai
2024-11-04 9:03 ` Binbin Wu
2024-11-04 8:49 ` Binbin Wu
2024-11-04 9:55 ` Huang, Kai
2024-11-05 1:07 ` Binbin Wu
2024-11-05 2:32 ` Sean Christopherson
2024-11-05 9:20 ` Huang, Kai
2024-11-06 8:32 ` Binbin Wu
2024-11-06 8:54 ` Huang, Kai
2024-11-06 10:11 ` Binbin Wu
2024-11-06 15:30 ` Sean Christopherson
2024-11-25 6:47 ` Binbin Wu
2024-11-25 12:08 ` Huang, Kai
2024-10-31 4:56 ` Binbin Wu
2024-10-31 15:11 ` Sean Christopherson
2024-08-26 2:22 ` [PATCH v3 2/2] KVM: x86: Use user_exit_on_hypercall() instead of opencode Binbin Wu
2024-10-09 6:49 ` Xiaoyao Li
2024-10-09 5:37 ` [PATCH v3 0/2] KVM: x86: Check hypercall's exit to userspace generically Binbin Wu
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=ZyTzNHil-55v7D3r@google.com \
--to=seanjc@google.com \
--cc=binbin.wu@linux.intel.com \
--cc=isaku.yamahata@intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
--cc=xiaoyao.li@intel.com \
--cc=yuan.yao@linux.intel.com \
/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.