All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david@gibson.dropbear.id.au>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
	"Paul Mackerras" <paulus@ozlabs.org>,
	kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: Book3S: Provide information about hardware/firmware CVE workarounds
Date: Thu, 18 Jan 2018 15:20:02 +1100	[thread overview]
Message-ID: <20180118042002.GG30352@umbus.fritz.box> (raw)
In-Reply-To: <19b0b672-ba88-b859-8a03-4a538bfc8c3a@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2592 bytes --]

On Wed, Jan 17, 2018 at 07:03:13PM +0100, Paolo Bonzini wrote:
> On 17/01/2018 15:27, Radim Krčmář wrote:
> > 2018-01-17 08:51+1100, Paul Mackerras:
> >> On Tue, Jan 16, 2018 at 03:45:11PM +0100, Paolo Bonzini wrote:
> >>> On 16/01/2018 01:59, Paul Mackerras wrote:
> >>>> This adds a new ioctl, KVM_PPC_GET_CPU_CHAR, that gives userspace
> >>>> information about the underlying machine's level of vulnerability
> >>>> to the recently announced vulnerabilities CVE-2017-5715,
> >>>> CVE-2017-5753 and CVE-2017-5754, and whether the machine provides
> >>>> instructions to assist software to work around the vulnerabilities.
> >>>>
> >>>> The ioctl returns two u64 words describing characteristics of the
> >>>> CPU and required software behaviour respectively, plus two mask
> >>>> words which indicate which bits have been filled in by the kernel,
> >>>> for extensibility.  The bit definitions are the same as for the
> >>>> new H_GET_CPU_CHARACTERISTICS hypercall.
> >>>>
> >>>> There is also a new capability, KVM_CAP_PPC_GET_CPU_CHAR, which
> >>>> indicates whether the new ioctl is available.
> >>>>
> >>>> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
> >>>> ---
> >>>
> >>> Thanks, looks good.  Would you like this in 4.15?
> >>
> >> Yes please.  Will you just apply the patch, or do you want me to put
> >> it in a branch for you to pull?
> > 
> > I can apply it directly.
> > 
> > Do I understand correctly that the interface is a KVM hypercall because
>                                                         ^^^^^^^^^
> 
> ioctl?
> 
> > we need to forward this information into guests and other userspace can
> > do nothing with the information?
> 
> There will probably be someone else that can consume it sooner or later.
>  sysfs or /proc/cpuinfo probably would be a better interface.  But I
> guess KVM is the prime consumer...

Even if we have a more general interface, I think we'll still want a
KVM specific one (even if it just draws the info from the general
one).  It's conceivable that there could be complications which make
one of these things behave different from the PoV of a guest than from
the PoV of a regular userspace program.

For that reason, I think it's best for qemu to draw this information
from KVM for passing to guests, even if there is a different source
that most userspace programs will use.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: David Gibson <david@gibson.dropbear.id.au>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Radim Krčmář" <rkrcmar@redhat.com>,
	"Paul Mackerras" <paulus@ozlabs.org>,
	kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
Subject: Re: [PATCH] KVM: PPC: Book3S: Provide information about hardware/firmware CVE workarounds
Date: Thu, 18 Jan 2018 04:20:02 +0000	[thread overview]
Message-ID: <20180118042002.GG30352@umbus.fritz.box> (raw)
In-Reply-To: <19b0b672-ba88-b859-8a03-4a538bfc8c3a@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2592 bytes --]

On Wed, Jan 17, 2018 at 07:03:13PM +0100, Paolo Bonzini wrote:
> On 17/01/2018 15:27, Radim Krčmář wrote:
> > 2018-01-17 08:51+1100, Paul Mackerras:
> >> On Tue, Jan 16, 2018 at 03:45:11PM +0100, Paolo Bonzini wrote:
> >>> On 16/01/2018 01:59, Paul Mackerras wrote:
> >>>> This adds a new ioctl, KVM_PPC_GET_CPU_CHAR, that gives userspace
> >>>> information about the underlying machine's level of vulnerability
> >>>> to the recently announced vulnerabilities CVE-2017-5715,
> >>>> CVE-2017-5753 and CVE-2017-5754, and whether the machine provides
> >>>> instructions to assist software to work around the vulnerabilities.
> >>>>
> >>>> The ioctl returns two u64 words describing characteristics of the
> >>>> CPU and required software behaviour respectively, plus two mask
> >>>> words which indicate which bits have been filled in by the kernel,
> >>>> for extensibility.  The bit definitions are the same as for the
> >>>> new H_GET_CPU_CHARACTERISTICS hypercall.
> >>>>
> >>>> There is also a new capability, KVM_CAP_PPC_GET_CPU_CHAR, which
> >>>> indicates whether the new ioctl is available.
> >>>>
> >>>> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
> >>>> ---
> >>>
> >>> Thanks, looks good.  Would you like this in 4.15?
> >>
> >> Yes please.  Will you just apply the patch, or do you want me to put
> >> it in a branch for you to pull?
> > 
> > I can apply it directly.
> > 
> > Do I understand correctly that the interface is a KVM hypercall because
>                                                         ^^^^^^^^^
> 
> ioctl?
> 
> > we need to forward this information into guests and other userspace can
> > do nothing with the information?
> 
> There will probably be someone else that can consume it sooner or later.
>  sysfs or /proc/cpuinfo probably would be a better interface.  But I
> guess KVM is the prime consumer...

Even if we have a more general interface, I think we'll still want a
KVM specific one (even if it just draws the info from the general
one).  It's conceivable that there could be complications which make
one of these things behave different from the PoV of a guest than from
the PoV of a regular userspace program.

For that reason, I think it's best for qemu to draw this information
from KVM for passing to guests, even if there is a different source
that most userspace programs will use.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2018-01-18  4:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-16  0:59 [PATCH] KVM: PPC: Book3S: Provide information about hardware/firmware CVE workarounds Paul Mackerras
2018-01-16  0:59 ` Paul Mackerras
2018-01-16 14:45 ` Paolo Bonzini
2018-01-16 14:45   ` Paolo Bonzini
2018-01-16 21:51   ` Paul Mackerras
2018-01-16 21:51     ` Paul Mackerras
2018-01-17 14:27     ` Radim Krčmář
2018-01-17 14:27       ` Radim Krčmář
2018-01-17 18:03       ` Paolo Bonzini
2018-01-17 18:03         ` Paolo Bonzini
2018-01-17 20:48         ` Paul Mackerras
2018-01-17 20:48           ` Paul Mackerras
2018-01-18  4:20         ` David Gibson [this message]
2018-01-18  4:20           ` David Gibson
2018-01-18  4:20       ` David Gibson
2018-01-18  4:20         ` David Gibson
2018-01-19  4:51 ` [PATCH v2] " Paul Mackerras
2018-01-19  4:51   ` Paul Mackerras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180118042002.GG30352@umbus.fritz.box \
    --to=david@gibson.dropbear.id.au \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=paulus@ozlabs.org \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.