Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Tue, 26 Apr 2022 22:00:18 +0800
From:   Chao Gao <chao.gao@intel.com>
To:     Maxim Levitsky <mlevitsk@redhat.com>
Cc:     Sean Christopherson <seanjc@google.com>,
        Zeng Guang <guang.zeng@intel.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        Wanpeng Li <wanpengli@tencent.com>,
        Jim Mattson <jmattson@google.com>,
        Joerg Roedel <joro@8bytes.org>, kvm@vger.kernel.org,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Tony Luck <tony.luck@intel.com>,
        Kan Liang <kan.liang@linux.intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Kim Phillips <kim.phillips@amd.com>,
        Jarkko Sakkinen <jarkko@kernel.org>,
        Jethro Beekman <jethro@fortanix.com>,
        Kai Huang <kai.huang@intel.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org, Robert Hu <robert.hu@intel.com>
Subject: Re: [PATCH v8 6/9] KVM: x86: lapic: don't allow to change APIC ID
 unconditionally
Message-ID: <20220426140013.GA11796@gao-cwp>
References: <20220411090447.5928-1-guang.zeng@intel.com>
 <20220411090447.5928-7-guang.zeng@intel.com>
 <YlmDtC73u/AouMsu@google.com>
 <080d6ced254e56dbad2910447f81c5ea976fc419.camel@redhat.com>
 <6475522c58aec5db3ee0a5ccd3230c63a2f013a9.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6475522c58aec5db3ee0a5ccd3230c63a2f013a9.camel@redhat.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

>Palo, Sean, Any update?
>
>After thinking more about this, I actualy think I will do something
>different, something that actually was proposed here, and I was against it:
>
>
>1. I will add new inhibit APICV_INHIBIT_REASON_RO_SETTINGS, which will be set
>first time any vCPU touches apic id and/or apic base because why not...
>
>That will take care of non nested case cleanly, and will take care of IPIv
>for now (as long as it does't support nesting).

Yes. This works well with intel IPIv.

>
>2. For my nested AVIC, I will do 2 things:
>
>   a. My code never reads L1 apic ids, and always uses vcpu_id, thus
>      in theory, if I just ignore the problem, and the guest changes apic ids,
>      the nested AVIC will just keep on using initial apic ids, thus there is  no danger
>      of CVE like issue if the guest tries to change theses ids in the 'right' time.
>
>   b. on each nested vm entry I'll just check that apic id is not changed from the default,
>      if AVIC is enabled for the nested guest.
>
>      if so the nested entry will fail (best with kvm_vm_bugged) to get attention of
>      the user, but I can just fail it with standard vm exit reason of 0xFFFFFFFF.

For sake of simplicity, I prefer to make APIC ID read-only for VMs that
supports (nested) AVIC or IPIv (KVM can check guest CPUID/MSR to know
this). When guest attempts to change read-only APIC ID, KVM can raise an
internal error, saying KVM cannot emulate this action. To get rid of such
an error, users should launch the VM with nested AVIC/IPIv disabled or
upgrade VM kernel to not change APIC ID.