linux-kernel - Re: [PATCH 4/4] KVM: x86: allow hotplug of VCPU with APIC ID over 0xff

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: <6f14273e-8429-18dc-6785-5f001b194bf1@redhat.com>
Date:   Tue, 6 Dec 2016 10:37:03 +0100
From:   David Hildenbrand <david@...hat.com>
To:     Radim Krčmář <rkrcmar@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>,
        Igor Mammedov <imammedo@...hat.com>
Subject: Re: [PATCH 4/4] KVM: x86: allow hotplug of VCPU with APIC ID over
 0xff

> I think the agreement is to embrace compatibility, so we pile new
> mistakes to hide known ones.
> (Rewriting the past requires far more power than accepting it:
>  If we didn't force unfixed kernels out of existence, then userspace
>  couldn't tell if hotplug up to high VCPU ID limit is supported.)

I agree, the question is how old the bug is (you should know better than 
me :) ) and if introducing a capability is strictly necessary. Do we 
have to do the check in QEMU or can we simply fix implementations out 
there silently.

(especially as hotplugging cpuid > 255 doesn't sound like setups wildly 
used already today - and it doesn't work ;) ). But as I said, I don't 
know the history, so you decide if this check in QEMU is necessary.

Fix all QEMUs (introduce capability check) vs fix all relevant kernels 
(limiting VCPU id to 255).

-- 

David