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

[Daniel P. Berrangé]

On Thu, Apr 04, 2019 at 10:00:21AM +0100, Peter Crowther wrote:
> On Thu, 4 Apr 2019 at 09:15, Daniel P. Berrangé <berrange at redhat.com> wrote:
> 
> > On Wed, Apr 03, 2019 at 07:49:48PM -0400, Cole Robinson wrote:
> > I
> > think it is reasonable to assume that if the user has upgraded the
> > microcode on some hosts they will have done it on all hosts.
> 
> 
> Don't rely on it - certainly in the cases of the smaller organisations I
> work with / audit, patching can be politely described as "haphazard".  Even
> in the large public-sector organisations I work with, there's almost never
> money for test rigs that have the same hardware as the live hosts.  It's
> not uncommon for a live host to be the "guinea pig" receiving new microcode
> before others, then returned to live service.
> 
> The real world is not tidy :-(.

Sure, that's why this series proposes a command line option to let the
user disable the security features if they are in a messy situations.

> 
> If they
> > have not upgraded on all hosts, I still think it is sensible to
> > apply the security mitigations on the hosts which have been upgraded
> > unless the user explicitly says to use the insecure mode.
> >
> 
> Agree.
> 
> We should do the right thing out of the box to enable the
> > security mitigations.  The fact that virt-intsall doesn't do this for
> > named CPU models is arguably worthy of filing a CVE against virt-install
> > itself.
> >
> 
> Agree.
> 
> >
> > Regards,
> > Daniel
> >
> 
> - Peter

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|