Re: [PATCH] KVM: PPC: Book3S: Provide information about hardware/firmware CVE workarounds

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
> >>>> ---
> >>>
> >>> 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: signature.asc
Description: PGP signature


[Index of Archives]     [KVM Development]     [KVM ARM]     [KVM ia64]     [Linux Virtualization]     [Linux USB Devel]     [Linux Video]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux