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: <Y20t0AMNqvtyOwp2@google.com>
Date:   Thu, 10 Nov 2022 16:58:56 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     "Huang, Kai" <kai.huang@...el.com>
Cc:     "farman@...ux.ibm.com" <farman@...ux.ibm.com>,
        "frankja@...ux.ibm.com" <frankja@...ux.ibm.com>,
        "mjrosato@...ux.ibm.com" <mjrosato@...ux.ibm.com>,
        "vkuznets@...hat.com" <vkuznets@...hat.com>,
        "chenhuacai@...nel.org" <chenhuacai@...nel.org>,
        "aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
        "palmer@...belt.com" <palmer@...belt.com>,
        "paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
        "maz@...nel.org" <maz@...nel.org>,
        "anup@...infault.org" <anup@...infault.org>,
        "imbrenda@...ux.ibm.com" <imbrenda@...ux.ibm.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "borntraeger@...ux.ibm.com" <borntraeger@...ux.ibm.com>,
        "aleksandar.qemu.devel@...il.com" <aleksandar.qemu.devel@...il.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "atishp@...shpatra.org" <atishp@...shpatra.org>,
        "farosas@...ux.ibm.com" <farosas@...ux.ibm.com>,
        "david@...hat.com" <david@...hat.com>,
        "Yao, Yuan" <yuan.yao@...el.com>,
        "mpe@...erman.id.au" <mpe@...erman.id.au>,
        "alexandru.elisei@....com" <alexandru.elisei@....com>,
        "linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "Yamahata, Isaku" <isaku.yamahata@...el.com>,
        "kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
        "james.morse@....com" <james.morse@....com>,
        "kvm-riscv@...ts.infradead.org" <kvm-riscv@...ts.infradead.org>,
        "suzuki.poulose@....com" <suzuki.poulose@....com>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
        "Gao, Chao" <chao.gao@...el.com>,
        "oliver.upton@...ux.dev" <oliver.upton@...ux.dev>,
        "kvmarm@...ts.cs.columbia.edu" <kvmarm@...ts.cs.columbia.edu>,
        "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH 38/44] KVM: Disable CPU hotplug during hardware enabling

On Thu, Nov 10, 2022, Huang, Kai wrote:
> On Thu, 2022-11-10 at 01:33 +0000, Huang, Kai wrote:
> > > @@ -9283,7 +9283,13 @@ static int
> > > kvm_x86_check_processor_compatibility(struct kvm_x86_init_ops *ops)
> > >  	int cpu = smp_processor_id();
> > >  	struct cpuinfo_x86 *c = &cpu_data(cpu);
> > >  
> > > -	WARN_ON(!irqs_disabled());
> > > +	/*
> > > +	 * Compatibility checks are done when loading KVM and when enabling
> > > +	 * hardware, e.g. during CPU hotplug, to ensure all online CPUs are
> > > +	 * compatible, i.e. KVM should never perform a compatibility check
> > > on
> > > +	 * an offline CPU.
> > > +	 */
> > > +	WARN_ON(!irqs_disabled() && cpu_active(cpu));
> > >  
> > 
> > Also, the logic of:
> > 
> > 	!irqs_disabled() && cpu_active(cpu)
> > 
> > is quite weird.
> > 
> > The original "WARN(!irqs_disabled())" is reasonable because in STARTING
> > section
> > the IRQ is indeed disabled.
> > 
> > But this doesn't make sense anymore after we move to ONLINE section, in which
> > IRQ has already been enabled (see start_secondary()).  IIUC the WARN_ON()
> > doesn't get exploded is purely because there's an additional cpu_active(cpu)
> > check.
> > 
> > So, a more reasonable check should be something like:
> > 
> > 	WARN_ON(irqs_disabled() || cpu_active(cpu) || !cpu_online(cpu));
> > 
> > Or we can simply do:
> > 
> > 	WARN_ON(!cpu_online(cpu) || cpu_active(cpu));
> > 
> > (because I don't know whether it's possible IRQ can somehow get disabled in
> > ONLINE section).
> > 
> > Btw above is purely based on code analysis, but I haven't done any test.
> 
> Hmm.. I wasn't thinking thoroughly.  I forgot CPU compatibility check also
> happens on all online cpus when loading KVM.  For this case, IRQ is disabled and
> cpu_active() is true.  For the hotplug case, IRQ is enabled but  cpu_active() is
> false.
> 
> So WARN_ON(!irqs_disabled() && cpu_active(cpu)) looks reasonable.  Sorry for the
> noise.  Just needed some time to connect the comment with the code.

No worries, more than once while working through this code, I've considered setting
up one of those evidence boards from the movies with string and push pins to help
connect all the dots.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ