Received-SPF: pass (google.com: domain of linux-kernel+bounces-48699-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Thu, 1 Feb 2024 18:30:02 +0000
From: Mingwei Zhang <mizhang@google.com>
To: Sean Christopherson <seanjc@google.com>
Cc: Dongli Zhang <dongli.zhang@oracle.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: x86/pmu: Fix type length error when reading
 pmu->fixed_ctr_ctrl
Message-ID: <ZbvjKtsVjpuQmKE2@google.com>
References: <20240123221220.3911317-1-mizhang@google.com>
 <ZbpqoU49k44xR4zB@google.com>
 <368248d0-d379-23c8-dedf-af7e1e8d23c7@oracle.com>
 <CAL715WJDesggP0S0M0SWX2QaFfjBNdqD1j1tDU10Qxk6h7O0pA@mail.gmail.com>
 <ZbvUyaEypRmb2s73@google.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <ZbvUyaEypRmb2s73@google.com>

On Thu, Feb 01, 2024, Sean Christopherson wrote:
> On Wed, Jan 31, 2024, Mingwei Zhang wrote:
> > On Wed, Jan 31, 2024 at 9:02 AM Dongli Zhang <dongli.zhang@oracle.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?
> 
> No, that can't happen, and KVM would have a massive bug if that were the case.
> The truncation can _only_ cause bits to disappear, it can't magically make bits
> appear, i.e. the _only_ way this can cause a problem is for KVM to incorrectly
> think a PMC is being disabled.

The reason why the bug does not happen is because there is global
control. So disabling a counter will be effectively done in the global
disable part, ie., when guest PMU writes to MSR 0x38f.

So this will be an ugly bug in an ancient PMU.
> 
> And FWIW, KVM does do the right thing (well, "right" might be too strong) when a

right thing? yes. too strong.

> fixed PMC is disabled. KVM will pause the counter in reprogram_counter(), and
> then leave the perf event paused counter as pmc_event_is_allowed() will return
> %false due to the PMC being locally disabled.
>
> But in this case, _if_ the counter is actually enabled, KVM will simply reprogram
> the PMC.  Reprogramming is unnecessary and wasteful, but it's not broken.

no, if the counter is actually enabled, but then it is assigned to
old_fixed_ctr_ctrl, the value is truncated. When control goes to the
check at the time of disabling the counter, KVM thinks it is disabled,
since the value is already truncated to 0. So KVM will skip by saying
"oh, the counter is already disabled, why reprogram? No need!".

> 
> Side topic, looking at this code made me realize just how terrible the names
> pmc_in_use and pmc_speculative_in_use() are.  "pmc_in_use" sounds like it tracks
> which PMCs have perf_events, and at first glance at kvm_pmu_cleanup(), it even
> _looks_ like that's the case.  But kvm_pmu_cleanup() is _skipping_ PMCs that are
> not "in use".  And conversely, there is nothing speculative about checking the
> local enable bit for a PMC.

pmc_in_use is a terrible name. It seems the only usage point is for
LBR...
> 
> I'll send patches to rename pmc_in_use to pmc_accessed, and pmc_speculative_in_use()
> to pmc_is_locally_enabled().

yes, I like pmc_is_locally_enabled(). But I don't know what is better
for pmc_in_use.

> 
> As for this one, unless someone spends the time to prove me wrong, it's destined
> for 6.9 with a changelog that says the bug is likely benign.

It is not benign, but does not matter for modern CPUs with Intel PerfMon
v2 and later. So, for virtualized environment, it might be still
critical for those VMs with PerfMon v1.

Thanks.
-Mingwei