Assigning to all packagers collectively, since there is no registered maintainer for this package.

CC'ing tv and mrambo3501

CC: (none) => marja11, mrambo, thierry.vignaud
Assignee: bugsquad => pkg-bugs

Patched package uploaded for Mageia 6.

Advisory:
========================

Updated libvirt package fixes security vulnerability:

Systems with microprocessors utilizing speculative execution and speculative execution of memory reads before the addresses of all prior memory writes are known may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis, aka Speculative Store Bypass (SSB), Variant 4 (CVE-2018-3639).

References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-3639
https://access.redhat.com/security/cve/cve-2018-3639
========================

Updated packages in core/updates_testing:
========================
lib64virt0-3.10.0-1.3.mga6.x86_64.rpm
lib64virt-devel-3.10.0-1.3.mga6.x86_64.rpm
libvirt-docs-3.10.0-1.3.mga6.x86_64.rpm
libvirt-utils-3.10.0-1.3.mga6.x86_64.rpm
wireshark-libvirt-3.10.0-1.3.mga6.x86_64.rpm

from libvirt-3.10.0-1.3.mga6.src.rpm


Testing procedure:
https://bugs.mageia.org/show_bug.cgi?id=14192#c7

Assignee: pkg-bugs => qa-bugs
Keywords: (none) => has_procedure

Mageia 6, x86_64

Installed the packages and followed the  link to the test procedure.
Installed virt-manager version 1.4.1.
# systemctl enable libvirtd.service
# systemctl start libvirtd.service
# systemctl status libvirtd.service
● libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled; vendor pre
   Active: active (running) since Sat 2018-05-26 20:23:41 BST; 8s ago
     Docs: man:libvirtd(8)
           https://libvirt.org
 Main PID: 20968 (libvirtd)
   CGroup: /system.slice/libvirtd.service
           ├─20968 /usr/sbin/libvirtd
           ├─21082 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.co
           └─21083 /sbin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/default.co

$ virt-manager
This brought up the gui and a notice that root password was needed.
Used the menus to try to create a virtual machine on a local partition but at the iso install stage it refused to continue - lost the actual message so am going back over the same path.

CC: (none) => tarazed25

Retrod the same steps and ended up with this message:
Unable to complete install: 'unsupported
configuration: CPU mode 'custom' for
x86_64 kvm domain on x86_64 host is not
supported by hypervisor'

raceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 88, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/create.py", line 2288, in _do_async_install
    guest.start_install(meter=meter)
  File "/usr/share/virt-manager/virtinst/guest.py", line 477, in start_install
    doboot, transient)
  File "/usr/share/virt-manager/virtinst/guest.py", line 405, in _create_guest
    self.domain.create()
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1069, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: unsupported configuration: CPU mode 'custom' for x86_64 kvm domain on x86_64 host is not supported by hypervisor

My specification was:
Name    = mageia5
OS      = Mageia 5
Install = Local CDROM/ISO
Memory  = 3072 MiB
CPUs    = 1
Storage = 20GB /fom/qemu/mga5_32

Don't know where CPU mode 'custom' comes from.  It does not correspond with any settings on offer.

The references lead to an exploit database but it is not clear if these test programs have any relation to libvirt.

Started from scratch again, retraced my steps but clicked configure before starting (something like that), specified a bridged network using host ethernet and started the installation process.  On this 4K screen text in the 800x600 window was perfectly legible but the installation dialogue was doubled within that window on a tiny scale with strange colours like green and magenta.  At 400x300 the text was illegible.  So this is an impossible task but I shall poke around and see if there is some way to change the resolution.

Fourth try.  Found something in preferences, display model?  Chose vgavm and was able to
continue but got into trouble because I forgot to specify the network parameter.
Carried on regardless and installed Mate, 1100+ packages in about three minutes.
Finished off and rebooted without a problem.  The desktop is functional but it still
needs networking, and a larger display would be good.

(In reply to Len Lawrence from comment #3)
> Mageia 6, x86_64
> 
...
> 
> $ virt-manager
> This brought up the gui and a notice that root password was needed.
> Used the menus to try to create a virtual machine on a local partition but
> at the iso install stage it refused to continue - lost the actual message so
> am going back over the same path.

Just create a group libvirt and assign your user to it.

My virtual machines are working, but I am travelling now. I have configured bridge mode and host device enp14s0: macvtap, so that I need a wired connection for better testing.

Ulrich

Networking is running and the screen scales with the size of the window, which is not what is required.  How to enlarge the screen but maintain the resolution?  This may be limited by the fact that only 16 MB is allocated for video memory.

Creating the libvirt group...

Found a number of configuration files in /etc/libvirt and noted that manual changes  might well be overridden by qemu(?).
Use virsh pool-edit <name of file without extension>

None of the configurations appear to affect the screen display or resolution.

Some further hints:

The iso must be owned by root.

I always select video mode virtio and 3D acceleration activated. You can select in Virt-Manager under View -> Scale display -> always.

The guest resolution can be set as usual, e.g. under System Settings for KDE Plasma users and will be maintained.

I lost my skill of virsh, because I can configure everything in Virt-Manager.

Hope that helps,

Ulrich

Thanks for the tips Ulrich.  I shall see if they can be applied here.

One further query - if the iso needs to be owned by root does that mean the installation needs to be repeated from scratch after changing ownership?  That one is a bit of a puzzle.

Right, thanks.  Changing the screen resolution internally works perfectly - why did I not think of that?

So basically, this all works but I am unsure what to do about this Spectre V4 mitigation.

The virtual machine file is owned by root with 0600 permissions and to my surprise the iso also belongs to root - probably accidental.

@ Len Lawrence(In reply to Len Lawrence from comment #12)
> Thanks for the tips Ulrich.  I shall see if they can be applied here.
> 
...
> 
> So basically, this all works but I am unsure what to do about this Spectre
> V4 mitigation.

That is not required by the testing procedure.

I tested now 2 VMs with Mga6 Gnome and Plasma on qcow2 files taking and deleting shapshots with Virt-Manager. Everything is working fine.

Started a new install with a qcow2-file from Fedora 28 KDE. Dto. Everything is working.

Tested internet connection, sound, mouse, usb plugin. The only problem I found so far: Copy & paste does not work with KDE Plasma. That is a known issue, no regression. I also do not know which features are related with libvirt.

Setting Whiteboard to OK.

Ulrich

Whiteboard: (none) => MGA-64-OK

advisory added to svn, validating

Keywords: (none) => advisory, validated_update
CC: (none) => tmb, sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2018-0262.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED