lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL715WJDesggP0S0M0SWX2QaFfjBNdqD1j1tDU10Qxk6h7O0pA@mail.gmail.com>
Date: Wed, 31 Jan 2024 09:13:13 -0800
From: Mingwei Zhang <mizhang@...gle.com>
To: Dongli Zhang <dongli.zhang@...cle.com>
Cc: Sean Christopherson <seanjc@...gle.com>, Paolo Bonzini <pbonzini@...hat.com>, 
	"H. Peter Anvin" <hpa@...or.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: x86/pmu: Fix type length error when reading pmu->fixed_ctr_ctrl

On Wed, Jan 31, 2024 at 9:02 AM Dongli Zhang <dongli.zhang@...cle.com> wrote:
>
>
>
> On 1/31/24 07:43, Sean Christopherson wrote:
> > On Tue, Jan 23, 2024, Mingwei Zhang wrote:
> >> Fix type length error since pmu->fixed_ctr_ctrl is u64 but the local
> >> variable old_fixed_ctr_ctrl is u8. Truncating the value leads to
> >> information loss at runtime. This leads to incorrect value in old_ctrl
> >> retrieved from each field of old_fixed_ctr_ctrl and causes incorrect code
> >> execution within the for loop of reprogram_fixed_counters(). So fix this
> >> type to u64.
> >
> > But what is the actual fallout from this?  Stating that the bug causes incorrect
> > code execution isn't helpful, that's akin to saying water is wet.
> >
> > If I'm following the code correctly, the only fallout is that KVM may unnecessarily
> > mark a fixed PMC as in use and reprogram it.  I.e. the bug can result in (minor?)
> > performance issues, but it won't cause functional problems.
>
> My this issue cause "Uhhuh. NMI received for unknown reason XX on CPU XX." at VM side?
>
> The PMC is still active while the VM side handle_pmi_common() is not going to handle it?

hmm, so the new value is '0', but the old value is non-zero, KVM is
supposed to zero out (stop) the fix counter), but it skips it. This
leads to the counter continuously increasing until it overflows, but
guest PMU thought it had disabled it. That's why you got this warning?

I did not see this warning on my side, but it seems possible.

Thanks.
-Mingwei
>
> Thank you very much!
>
> Dongli Zhang
>
> >
> > Understanding what actually goes wrong matters, because I'm trying to determine
> > whether or not this needs to be fixed in 6.8 and backported to stable trees.  If
> > the bug is relatively benign, then this is fodder for 6.9.
> >
> >> Fixes: 76d287b2342e ("KVM: x86/pmu: Drop "u8 ctrl, int idx" for reprogram_fixed_counter()")
> >> Signed-off-by: Mingwei Zhang <mizhang@...gle.com>
> >> ---
> >>  arch/x86/kvm/vmx/pmu_intel.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intelc
> >> index a6216c874729..315c7c2ba89b 100644
> >> --- a/arch/x86/kvm/vmx/pmu_intel.c
> >> +++ b/arch/x86/kvm/vmx/pmu_intel.c
> >> @@ -71,7 +71,7 @@ static int fixed_pmc_events[] = {
> >>  static void reprogram_fixed_counters(struct kvm_pmu *pmu, u64 data)
> >>  {
> >>      struct kvm_pmc *pmc;
> >> -    u8 old_fixed_ctr_ctrl = pmu->fixed_ctr_ctrl;
> >> +    u64 old_fixed_ctr_ctrl = pmu->fixed_ctr_ctrl;
> >>      int i;
> >>
> >>      pmu->fixed_ctr_ctrl = data;
> >>
> >> base-commit: 6613476e225e090cc9aad49be7fa504e290dd33d
> >> --
> >> 2.43.0.429.g432eaa2c6b-goog
> >>
> >

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ