linux-kernel - Re: [PATCH 2/5] KVM: selftests: Only validate counts for hardware-supported arch events

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: <e939590d-c30a-4e00-be7c-584d4e80ec83@redhat.com>
Date: Mon, 20 Jan 2025 17:12:07 +0100
From: Paolo Bonzini <pbonzini@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>,
 Mingwei Zhang <mizhang@...gle.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
 kernel test robot <oliver.sang@...el.com>
Subject: Re: [PATCH 2/5] KVM: selftests: Only validate counts for
 hardware-supported arch events

On 1/18/25 01:39, Sean Christopherson wrote:
> On Sat, Jan 18, 2025, Mingwei Zhang wrote:
>> On Fri, Jan 17, 2025, Sean Christopherson wrote:
>>> @@ -582,18 +585,26 @@ static void test_intel_counters(void)
>>>   
>>>   	/*
>>>   	 * Detect the existence of events that aren't supported by selftests.
>>> -	 * This will (obviously) fail any time the kernel adds support for a
>>> -	 * new event, but it's worth paying that price to keep the test fresh.
>>> +	 * This will (obviously) fail any time hardware adds support for a new
>>> +	 * event, but it's worth paying that price to keep the test fresh.
>>>   	 */
>>>   	TEST_ASSERT(nr_arch_events <= NR_INTEL_ARCH_EVENTS,
>>>   		    "New architectural event(s) detected; please update this test (length = %u, mask = %x)",
>>> -		    nr_arch_events, kvm_cpu_property(X86_PROPERTY_PMU_EVENTS_MASK));
>>> +		    nr_arch_events, this_cpu_property(X86_PROPERTY_PMU_EVENTS_MASK));
>>
>> This is where it would make troubles for us (all companies that might be
>> using the selftest in upstream kernel and having a new hardware). In
>> this case when we get new hardware, the test will fail in the downstream
>> kernel. We will have to wait until the fix is ready, and backport it
>> downstream, re-test it.... It takes lots of extra work.
> 
> If Intel can't upstream what should be a *very* simple patch to enumerate the
> new encoding and its expected count in advance of hardware being shipped to
> partners, then we have bigger problems.

Conceptually I have bigger problems with people running stable kernels 
than people running on really really new hardware.

However the intersection of running a pretty old kernel on a very new 
bare metal x86 system is relatively small but nonzero (those pesky 
Debian users); it may happen with cloud instances but then the 
intersection of running old selftests in a nested virt environment is 
probably even smaller.

I am not too happy about the assertion, but it does seem like the lesser 
evil.

Paolo