On 09/01/2018 10:16, Wei Wang wrote: > On 01/09/2018 04:43 PM, Liran Alon wrote: >> ----- wei.w.wang@xxxxxxxxx wrote: >> >>> This patch shows an alternative approach to the one posted here: >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mail-2Darchive.com_linux-2Dkernel-40vger.kernel.org_msg1580364.html&d=DwIBAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=Jk6Q8nNzkQ6LJ6g42qARkg6ryIDGQr-yKXPNGZbpTx0&m=o_uh0-IfLdLMwf2MaOOQVKtZbPlJ-fDVmglRj277cwk&s=j1oGOoYysZhUuGuuvuwdTU_OO7bv1ysIyvDtAlc6C-c&e= >>> >>> >>> The advantages are >>> 1) Simpler; >>> 2) More reasonable because this is used to fill the hardware security >>> hole, for all the x86 cpus that physically support the two CPUIDs, >>> which means the hole already exists physically. All the VMs should >>> use this feature no matter what CPU model they are using. So, >> I'm not sure I 100% agree with this. >> There should be a way for the userspace agent to disable these CPUIDs >> if wanted. >> You don't want to lose the ability to expose a mimic of a real >> physical CPU-model of core2duo that >> doesn't have these CPUIDs. A good solution can be that these features >> will be exposed by default to guests >> if available on hardware but can still be explicitly not-exposed if >> userspace agent wishes so. > > I think the case we are handling here is different: > It shouldn't be treated as a regular feature (e.g. xsaves) that a user > can choose to use or not. It is a security hole (or say a bug). When we > fixed a bug, we don't give users an option to select to trigger the bug, > right? The user is free to do whatever it wants. For example, you could use KVM with an old CPU model to test the performance effect of IBRS on a guest, or to reverse engineer whether the guest is using IBRS or retpolines or whatever, and so on. Policy isn't implemented in KVM, QEMU or even libvirt. >> The only weird side-effect of this is that live-migration between >> different physical hosts running with >> exact same QEMU cmdline will result in different CPUID values exposed >> to guest. > > I think live migration itself doesn't do the CPUID check, so adding the > QEMU side hardcode part doesn't help. That is, even using that patch > 7/7, I think it wouldn't make a difference. > This is the same case when we migrate a VM from a skylake physical > machine to an older machine, the difference of supported CPUID won't > even generate a warning when the destination side QEMU gets booted, right? But we support it by using "-cpu Haswell" when we start the machine on a Skylake. Patch 7 is ugly right now, but it will be just a usual "add CPUID bits" patch as soon as Linux gets the cpufeature. A security-related feature is a good reason to fast track adding the CPUID bits, it's not a good reason to bypass all the lessons that we've learnt through the years about guest ABI and live migration. Paolo
