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@xxxxxxxxxx> 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 :| _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
