[virt-tools-list] [virt-manager PATCH 0/5] CPU security features improvements

[Pavel Hrdina]

On Wed, Apr 03, 2019 at 07:49:48PM -0400, Cole Robinson wrote:
> ccing danpb
> 
> On 4/3/19 9:52 AM, Pavel Hrdina wrote:
> > Pavel Hrdina (5):
> >   domcapabilities: remove recommended CPU features from security
> >     features
> >   domcapabilities: fix typo in function name
> >   cli: introduce CPU secure parameter
> >   domcapabilities: add caching of CPU security features
> >   virt-manager: add new checkbox to control CPU security features
> > 
> 
> So the bug spawning the original work is:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1582667
> 
> Some CPU model names lack security critical CPU flags. Example
> Opteron_G5 lacks ibpb. Even if the user is running on an Opteron_G5 host
> CPU which has ibpb, if they select Opteron_G5 the guest doesn't see it.
> 
> In that case, the existing patches in git will check to see if the host
> supports ibpb, and if so, manually specify that <feature> in the <cpu>
> config. So now use of --cpu Opteron_G5 is secure by default.
> 
> But the problem is this creates a migration compat issue: selecting
> --cpu Opteron_G5 means different things for different hosts. So these
> patches basically make the 'secure' <feature> additions the default
> behavior, but gives users the option to turn it off on the cli and
> virt-manager UI.
> 
> Taking a step back, I don't really get what the usecase is for users to
> be selecting manual cpu model names with virt-manager or virt-install. I
> understand the migration compat thing, if you need to generate a
> baseline CPU that works for migrating a machine across multiple hosts,
> but in practice that seems like pretty advanced usage for people using
> virt-manager or even virt-install, and if they are using virt-install
> they have all the tools at their disposal to generate a full + secure
> <cpu> config if they want.
> 
> That bug was filed in may of last year. When it was filed, virt-manager
> was still using the CPU model from 'virsh capabilities' as the default.
> With spectre stuff that is very bad for sure, because once we set
> Opteron_G5 it's there forever in the VM config, even after the host is
> updated to possibly expose more CPU flags or whatever, the VM always
> sees the old feature set.
> 
> However now we are defaulting to host-model for new enough qemu+libvirt,
> including in RHEL7 it seems. The default VM CPU config is as safe as the
> host CPU allows. So maybe the original motivation for the bug isn't
> really as valid any more because we use a better default.
> 
> So I kind of suspect that the original urgency around the bug was due to
> virt-manager potentially defaulting to the insecure model=Opteron_G5
> 
> Anyways, since the current code requires the user to explicitly opt in
> to choosing a manual CPU model name, what if instead we just warn them?
> A warning label that appears like:
> 
> "The following host security features are not supported by the selected
> CPU: ipbp, ...
> 
> Use 'Copy host CPU' for maximum security'"
> 
> And a virt-install printed warning to that effect too. Maybe we keep the
> --cpu secure=on CLI option but we keep it off by default. Basically if
> people are going to deviate from the default and specify a manual cpu
> name I don't think we need to bend over backwards to protect them in
> that case, just tell them 'dont do that' or if they have valid poweruser
> usecases then they have all the tools at their disposal to make it work,
> at least on the cli.

I agree with all of the reasoning you wrote except the RHEL7 part, we
cannot default to host-model, in order to do that you need to have
libvirt >= 3.2.0 and QEMU >= 2.9.0, or without a version check in
domain capabilities you can check if fallback='forbid':

  ...
  <cpu>
    ...
    <mode name='host-model' supported='yes'>
      <model fallback='forbid'>Skylake-Client-IBRS</model>
      ...
    </mode>
    ...
  </cpu>
  ...


From upstream POV all of these CPU security patches will probably help
only few users which will for whatever reason select specific CPU model
without where the warning would be good enough, but on RHEL7 the default
is still and always will be host-model-only so RHEL7 is by default
insecure.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20190404/cb8e4f6c/attachment.sig>