Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <FAFB5DA6-FA6F-4A1A-AB10-4B99F314B23D@gmail.com>
Date: Wed, 17 Jun 2020 23:59:10 -0700
From: Nadav Amit <nadav.amit@...il.com>
To: "Andersen, John" <john.s.andersen@...el.com>
Cc: corbet@....net,
 Paolo Bonzini <pbonzini@...hat.com>,
 Thomas Gleixner <tglx@...utronix.de>,
 mingo <mingo@...hat.com>,
 bp <bp@...en8.de>,
 hpa@...or.com,
 shuah@...nel.org,
 Sean Christopherson <sean.j.christopherson@...el.com>,
 rick.p.edgecombe@...el.com,
 kvm <kvm@...r.kernel.org>,
 kernel-hardening@...ts.openwall.com
Subject: Re: [kvm-unit-tests PATCH] x86: Add control register pinning tests

> On Jun 17, 2020, at 10:08 PM, Andersen, John <john.s.andersen@...el.com> wrote:
> 
> On Wed, Jun 17, 2020 at 08:18:39PM -0700, Nadav Amit wrote:
>>> On Jun 17, 2020, at 3:52 PM, Nadav Amit <nadav.amit@...il.com> wrote:
>>> 
>>>> On Jun 17, 2020, at 3:46 PM, John Andersen <john.s.andersen@...el.com> wrote:
>>>> 
>>>> Paravirutalized control register pinning adds MSRs guests can use to
>>>> discover which bits in CR0/4 they may pin, and MSRs for activating
>>>> pinning for any of those bits.
>>> 
>>> [ sni[
>>> 
>>>> +static void vmx_cr_pin_test_guest(void)
>>>> +{
>>>> +	unsigned long i, cr0, cr4;
>>>> +
>>>> +	/* Step 1. Skip feature detection to skip handling VMX_CPUID */
>>>> +	/* nop */
>>> 
>>> I do not quite get this comment. Why do you skip checking whether the
>>> feature is enabled? What happens if KVM/bare-metal/other-hypervisor that
>>> runs this test does not support this feature?
>> 
>> My bad, I was confused between the nested checks and the non-nested ones.
>> 
>> Nevertheless, can we avoid situations in which
>> rdmsr(MSR_KVM_CR0_PIN_ALLOWED) causes #GP when the feature is not
>> implemented? Is there some protocol for detection that this feature is
>> supported by the hypervisor, or do we need something like rdmsr_safe()?
> 
> Ah, yes we can. By checking the CPUID for the feature bit. Thanks for pointing
> this out, I was confused about this. I was operating under the assumption that
> the unit tests assume the features in the latest kvm/next are present and
> available when the unit tests are being run.
> 
> I'm happy to add the check, but I haven't see anywhere else where a
> KVM_FEATURE_ was checked for. Which is why it doesn't check in this patch. As
> soon as I get an answer from you or anyone else as to if the unit tests assume
> that the features in the latest kvm/next are present and available or not when
> the unit tests are being run I'll modify if necessary.

I would appreciate if you add a check of CPUID and not run the test if the 
feature is not supported.

I run the tests on bare-metal (and other non-KVM environment) from time to
time. Doing so allows to find bugs in tests due to wrong assumptions of KVM
test developers. Liran runs the tests using QEMU/WHPX (non-KVM). So allowing
the tests to run on non-KVM environments is important, at least for some of
us, and benefits KVM as well.

While I can disable this specific test using the test parameters, I prefer
that the test will first check the environment they run on. Debugging test
failures on bare-metal is hard enough without the paravirt stuff noise.

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.