Message ID | 20180111093147.GF24294@fergus.ozlabs.ibm.com |
---|---|
State | Rejected |
Headers | show |
Series | [GIT,PULL] Please pull paulus/powerpc kvm-ppc-cve-4.15 tag | expand |
On 11/01/2018 10:31, Paul Mackerras wrote: > Hi Paolo, > > This is a pull request for a commit that adds three new KVM > capabilities as part of the mitigation for the recently announced > exploits CVE-2017-5715, CVE-2017-5753 and CVE-2017-5754 (also known as > meltdown and spectre). These capabilities tell userspace about > whether the host machine has the vulnerabilities, and if so, whether > it has updated firmware that enables the machine to provide > instructions to help work around the vulnerabilities. > > Michael Ellerman has put the changes needed for kernels to use the > workaround instructions to work around CVE-2017-5754 (meltdown) into > his fixes branch and intends to ask Linus to pull them for 4.15. In a > guest kernel, the workarounds depend on getting information from the > platform from a new H_GET_CPU_CHARACTERISTICS hypercall. These > capabilities provide the information that userspace (e.g. QEMU) needs > in order to implement that hypercall. In the absence of the > hypercall, patched guest kernels will assume the machine is vulnerable > and will use a (slow) displacement flush loop to flush the L1 cache > each time the kernel exits to userspace. Why three capabilities? Could KVM just return KVM_PPC_GET_HOST_CPU_CHARACTERISTICS (perhaps only the characteristics word and not the behavior ones)? I agree this can go in for 4.15 though. Thanks, Paolo > > I leave it to your discretion as to whether to push it to Linus to go > in 4.15, or merge it in the 4.16 merge window. If it was up to me, I > would go for 4.15. In either case, please merge it to the kvm tree so > that the capability numbers get stabilized and the corresponding QEMU > patches can get merged. > > The pull request includes one commit from Michael Ellerman's tree via > his topic/ppc-kvm branch, because that commit adds definitions that > are used in implementing the capability tests. > > Thanks, > Paul. > > The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215: > > Linux 4.15-rc2 (2017-12-03 11:01:47 -0500) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc tags/kvm-ppc-cve-4.15 > > for you to fetch changes up to f6021f88d8ffefae616c33f70063e435209dad92: > > KVM: PPC: Book3S: Add capabilities for hardware/firmware CVE workarounds (2018-01-11 20:04:57 +1100) > > ---------------------------------------------------------------- > One commit, that adds three new KVM capabilities, which inform > userspace about the machine's vulnerability to recently-announced > vulnerabilities CVE-2017-5715, CVE-2017-5753 and CVE-2017-5754. > This gives userspace information needed to implement the new > H_GET_CPU_CHARACTERISTICS hypercall for pseries VMs. > > ---------------------------------------------------------------- > Michael Neuling (1): > powerpc/pseries: Add H_GET_CPU_CHARACTERISTICS flags & wrapper > > Paul Mackerras (1): > KVM: PPC: Book3S: Add capabilities for hardware/firmware CVE workarounds > > Documentation/virtual/kvm/api.txt | 36 ++++++ > arch/powerpc/include/asm/hvcall.h | 17 +++ > arch/powerpc/include/asm/plpar_wrappers.h | 14 +++ > arch/powerpc/kvm/powerpc.c | 200 ++++++++++++++++++++++++++++++ > include/uapi/linux/kvm.h | 3 + > 5 files changed, 270 insertions(+) > > - -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 11, 2018 at 11:51:53AM +0100, Paolo Bonzini wrote: > On 11/01/2018 10:31, Paul Mackerras wrote: > > Hi Paolo, > > > > This is a pull request for a commit that adds three new KVM > > capabilities as part of the mitigation for the recently announced > > exploits CVE-2017-5715, CVE-2017-5753 and CVE-2017-5754 (also known as > > meltdown and spectre). These capabilities tell userspace about > > whether the host machine has the vulnerabilities, and if so, whether > > it has updated firmware that enables the machine to provide > > instructions to help work around the vulnerabilities. > > > > Michael Ellerman has put the changes needed for kernels to use the > > workaround instructions to work around CVE-2017-5754 (meltdown) into > > his fixes branch and intends to ask Linus to pull them for 4.15. In a > > guest kernel, the workarounds depend on getting information from the > > platform from a new H_GET_CPU_CHARACTERISTICS hypercall. These > > capabilities provide the information that userspace (e.g. QEMU) needs > > in order to implement that hypercall. In the absence of the > > hypercall, patched guest kernels will assume the machine is vulnerable > > and will use a (slow) displacement flush loop to flush the L1 cache > > each time the kernel exits to userspace. > > Why three capabilities? Could KVM just return > KVM_PPC_GET_HOST_CPU_CHARACTERISTICS (perhaps only the characteristics > word and not the behavior ones)? The three capabilities were what came out of a discussion with David Gibson about how QEMU would implement the H_GET_CPU_CHARACTERISTICS hypercall. David wanted to be able to set a required minimum level of capability across a cluster of machines (i.e. migration domain) so that a guest that was expecting a certain level of security could rely on getting that regardless of which host it got migrated to. Expressing the host capability in terms of broken/workaround/fixed for each of the potential vulnerabilities seemed like the clearest way to represent the situation. QEMU can then have a minimum security level set on the command line, check that against the host capabilities, and only advertise the minimum level to guests. Thus QEMU might tell the guest via the H_GET_CPU_CHARACTERISTICS hypercall that it needs to apply workarounds even on a host which is actually fixed (the workaround instructions would be no-ops in that case), so that the guest can then be migrated to a host which needs the workarounds. As to the representation, we could have defined an ioctl to return the "character" and "behaviour" words just like H_GET_CPU_CHARACTERISTICS. We would need the "behaviour" word because that's how we will tell the guest which workarounds it doesn't need to implement, on machines which don't have one or more of the vulnerabilities. However, QEMU can't pass that information unmodified to the guest in general, and I think David felt the logic would be clearer working from a separate state for each vulnerability rather than having to decode that information from the "character" and "behaviour" words. If you think that a new ioctl returning character+behaviour is preferable, I can code that up easily enough. Regards, Paul. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 11/01/2018 23:15, Paul Mackerras wrote: > QEMU can then have a minimum security level set on the command line, > check that against the host capabilities, and only advertise the > minimum level to guests. Thus QEMU might tell the guest via the > H_GET_CPU_CHARACTERISTICS hypercall that it needs to apply workarounds > even on a host which is actually fixed (the workaround instructions > would be no-ops in that case), so that the guest can then be migrated > to a host which needs the workarounds. Agreed. > As to the representation, we could have defined an ioctl to return the > "character" and "behaviour" words just like H_GET_CPU_CHARACTERISTICS. > We would need the "behaviour" word because that's how we will tell the > guest which workarounds it doesn't need to implement, on machines > which don't have one or more of the vulnerabilities. Oh, my (probably wrong) understanding was that "behavior" can be chosen exclusively by QEMU, while "characteristics" are dictated by the host CPU. > However, QEMU > can't pass that information unmodified to the guest in general, and I > think David felt the logic would be clearer working from a separate > state for each vulnerability rather than having to decode that > information from the "character" and "behaviour" words. I think converting from characteristics to single vulnerabilities is QEMU's job. For KVM I prefer an API that is easier to extend and doesn't require a proliferation of capabilities. Thanks, Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html