[GIT,PULL] Please pull paulus/powerpc kvm-ppc-cve-4.15 tag

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.

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 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