* [PATCH] KVM: apic: avoid calculating pending eoi from an uninitialized val
@ 2020-02-20 15:36 linmiaohe
2020-02-20 16:33 ` Vitaly Kuznetsov
0 siblings, 1 reply; 5+ messages in thread
From: linmiaohe @ 2020-02-20 15:36 UTC (permalink / raw)
To: pbonzini, rkrcmar, sean.j.christopherson, vkuznets, wanpengli,
jmattson, joro, tglx, mingo, bp, hpa
Cc: linmiaohe, kvm, linux-kernel, x86
From: Miaohe Lin <linmiaohe@huawei.com>
When get user eoi value failed, var val would be uninitialized and result
in calculating pending eoi from an uninitialized val. Initialize var val
to 0 to fix this case.
Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
---
arch/x86/kvm/lapic.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 4f14ec7525f6..7e77e94f3176 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -626,7 +626,7 @@ static inline bool pv_eoi_enabled(struct kvm_vcpu *vcpu)
static bool pv_eoi_get_pending(struct kvm_vcpu *vcpu)
{
- u8 val;
+ u8 val = 0;
if (pv_eoi_get_user(vcpu, &val) < 0)
printk(KERN_WARNING "Can't read EOI MSR value: 0x%llx\n",
(unsigned long long)vcpu->arch.pv_eoi.msr_val);
--
2.19.1
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH] KVM: apic: avoid calculating pending eoi from an uninitialized val
2020-02-20 15:36 [PATCH] KVM: apic: avoid calculating pending eoi from an uninitialized val linmiaohe
@ 2020-02-20 16:33 ` Vitaly Kuznetsov
2020-02-20 17:20 ` Sean Christopherson
0 siblings, 1 reply; 5+ messages in thread
From: Vitaly Kuznetsov @ 2020-02-20 16:33 UTC (permalink / raw)
To: linmiaohe
Cc: kvm, linux-kernel, x86, pbonzini, rkrcmar, sean.j.christopherson,
wanpengli, jmattson, joro, tglx, mingo, bp, hpa
linmiaohe <linmiaohe@huawei.com> writes:
> From: Miaohe Lin <linmiaohe@huawei.com>
>
> When get user eoi value failed, var val would be uninitialized and result
> in calculating pending eoi from an uninitialized val. Initialize var val
> to 0 to fix this case.
Let me try to suggest an alternative wording,
"When pv_eoi_get_user() fails, 'val' may remain uninitialized and the
return value of pv_eoi_get_pending() becomes random. Fix the issue by
initializing the variable."
>
> Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> ---
> arch/x86/kvm/lapic.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> index 4f14ec7525f6..7e77e94f3176 100644
> --- a/arch/x86/kvm/lapic.c
> +++ b/arch/x86/kvm/lapic.c
> @@ -626,7 +626,7 @@ static inline bool pv_eoi_enabled(struct kvm_vcpu *vcpu)
>
> static bool pv_eoi_get_pending(struct kvm_vcpu *vcpu)
> {
> - u8 val;
> + u8 val = 0;
> if (pv_eoi_get_user(vcpu, &val) < 0)
> printk(KERN_WARNING "Can't read EOI MSR value: 0x%llx\n",
> (unsigned long long)vcpu->arch.pv_eoi.msr_val);
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
But why compilers don't complain?
--
Vitaly
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH] KVM: apic: avoid calculating pending eoi from an uninitialized val
2020-02-20 16:33 ` Vitaly Kuznetsov
@ 2020-02-20 17:20 ` Sean Christopherson
0 siblings, 0 replies; 5+ messages in thread
From: Sean Christopherson @ 2020-02-20 17:20 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: linmiaohe, kvm, linux-kernel, x86, pbonzini, rkrcmar, wanpengli,
jmattson, joro, tglx, mingo, bp, hpa
On Thu, Feb 20, 2020 at 05:33:17PM +0100, Vitaly Kuznetsov wrote:
> linmiaohe <linmiaohe@huawei.com> writes:
>
> > From: Miaohe Lin <linmiaohe@huawei.com>
> >
> > When get user eoi value failed, var val would be uninitialized and result
> > in calculating pending eoi from an uninitialized val. Initialize var val
> > to 0 to fix this case.
>
> Let me try to suggest an alternative wording,
>
> "When pv_eoi_get_user() fails, 'val' may remain uninitialized and the
> return value of pv_eoi_get_pending() becomes random. Fix the issue by
> initializing the variable."
>
> >
> > Signed-off-by: Miaohe Lin <linmiaohe@huawei.com>
> > ---
> > arch/x86/kvm/lapic.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index 4f14ec7525f6..7e77e94f3176 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -626,7 +626,7 @@ static inline bool pv_eoi_enabled(struct kvm_vcpu *vcpu)
> >
> > static bool pv_eoi_get_pending(struct kvm_vcpu *vcpu)
> > {
> > - u8 val;
> > + u8 val = 0;
Rather than initialize @val, I'd prefer to explicitly handle the error,
similar to pv_eoi_clr_pending() and pv_eoi_set_pending(), e.g.
u8 val;
if (pv_eoi_get_user(vcpu, &val) < 0) {
printk(KERN_WARNING "Can't read EOI MSR value: 0x%llx\n",
(unsigned long long)vcpu->arch.pv_eoi.msr_val);
return false;
}
return val & 0x1;
> > if (pv_eoi_get_user(vcpu, &val) < 0)
> > printk(KERN_WARNING "Can't read EOI MSR value: 0x%llx\n",
> > (unsigned long long)vcpu->arch.pv_eoi.msr_val);
>
> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>
> But why compilers don't complain?
Clang might?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] KVM: apic: avoid calculating pending eoi from an uninitialized val
@ 2020-02-21 1:31 linmiaohe
0 siblings, 0 replies; 5+ messages in thread
From: linmiaohe @ 2020-02-21 1:31 UTC (permalink / raw)
To: Vitaly Kuznetsov
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org,
pbonzini@redhat.com, rkrcmar@redhat.com,
sean.j.christopherson@intel.com, wanpengli@tencent.com,
jmattson@google.com, joro@8bytes.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, hpa@zytor.com
Vitaly Kuznetsov <vkuznets@redhat.com> writes:
>linmiaohe <linmiaohe@huawei.com> writes:
>> When get user eoi value failed, var val would be uninitialized and
>> result in calculating pending eoi from an uninitialized val.
>> Initialize var val to 0 to fix this case.
>
>Let me try to suggest an alternative wording,
>
>"When pv_eoi_get_user() fails, 'val' may remain uninitialized and the return value of pv_eoi_get_pending() becomes random. Fix the issue by initializing the variable."
Sounds much better. You're really good at it. :) Thanks.
>>
>>
>Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>
>But why compilers don't complain?
Maybe it's because @val only remain uninitialized when pv_eoi_get_user() failed?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] KVM: apic: avoid calculating pending eoi from an uninitialized val
@ 2020-02-21 1:36 linmiaohe
0 siblings, 0 replies; 5+ messages in thread
From: linmiaohe @ 2020-02-21 1:36 UTC (permalink / raw)
To: Sean Christopherson, Vitaly Kuznetsov
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org,
pbonzini@redhat.com, rkrcmar@redhat.com, wanpengli@tencent.com,
jmattson@google.com, joro@8bytes.org, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, hpa@zytor.com
Sean Christopherson <sean.j.christopherson@intel.com> wrote:
>On Thu, Feb 20, 2020 at 05:33:17PM +0100, Vitaly Kuznetsov wrote:
>> linmiaohe <linmiaohe@huawei.com> writes:
>>
>
>Rather than initialize @val, I'd prefer to explicitly handle the error, similar to pv_eoi_clr_pending() and pv_eoi_set_pending(), e.g.
>
> u8 val;
>
> if (pv_eoi_get_user(vcpu, &val) < 0) {
> printk(KERN_WARNING "Can't read EOI MSR value: 0x%llx\n",
> (unsigned long long)vcpu->arch.pv_eoi.msr_val);
> return false;
> }
> return val & 0x1;
Looks good. Handle the error explicitly can help remind us @val is unusable.
Will do. Thanks.
>> > if (pv_eoi_get_user(vcpu, &val) < 0)
>> > printk(KERN_WARNING "Can't read EOI MSR value: 0x%llx\n",
>> > (unsigned long long)vcpu->arch.pv_eoi.msr_val);
>>
>> Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
>>
>> But why compilers don't complain?
>
>Clang might?
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-02-21 1:36 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-02-20 15:36 [PATCH] KVM: apic: avoid calculating pending eoi from an uninitialized val linmiaohe
2020-02-20 16:33 ` Vitaly Kuznetsov
2020-02-20 17:20 ` Sean Christopherson
-- strict thread matches above, loose matches on Subject: below --
2020-02-21 1:31 linmiaohe
2020-02-21 1:36 linmiaohe
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).