Here comes virtualbox with fixes/mitigations for Meltdown/Spectre.... SRPMS: kmod-vboxadditions-5.2.6-1.mga6.src.rpm kmod-virtualbox-5.2.6-1.mga6.src.rpm virtualbox-5.2.6-1.mga6.src.rpm i586: dkms-vboxadditions-5.2.6-1.mga6.noarch.rpm dkms-virtualbox-5.2.6-1.mga6.noarch.rpm python-virtualbox-5.2.6-1.mga6.i586.rpm vboxadditions-kernel-4.14.13-desktop-1.mga6-5.2.6-1.mga6.i586.rpm vboxadditions-kernel-4.14.13-desktop586-1.mga6-5.2.6-1.mga6.i586.rpm vboxadditions-kernel-4.14.13-server-1.mga6-5.2.6-1.mga6.i586.rpm vboxadditions-kernel-desktop586-latest-5.2.6-1.mga6.i586.rpm vboxadditions-kernel-desktop-latest-5.2.6-1.mga6.i586.rpm vboxadditions-kernel-server-latest-5.2.6-1.mga6.i586.rpm virtualbox-5.2.6-1.mga6.i586.rpm virtualbox-devel-5.2.6-1.mga6.i586.rpm virtualbox-guest-additions-5.2.6-1.mga6.i586.rpm virtualbox-kernel-4.14.13-desktop-1.mga6-5.2.6-1.mga6.i586.rpm virtualbox-kernel-4.14.13-desktop586-1.mga6-5.2.6-1.mga6.i586.rpm virtualbox-kernel-4.14.13-server-1.mga6-5.2.6-1.mga6.i586.rpm virtualbox-kernel-desktop586-latest-5.2.6-1.mga6.i586.rpm virtualbox-kernel-desktop-latest-5.2.6-1.mga6.i586.rpm virtualbox-kernel-server-latest-5.2.6-1.mga6.i586.rpm x11-driver-video-vboxvideo-5.2.6-1.mga6.i586.rpm x86_64: dkms-vboxadditions-5.2.6-1.mga6.noarch.rpm dkms-virtualbox-5.2.6-1.mga6.noarch.rpm python-virtualbox-5.2.6-1.mga6.x86_64.rpm vboxadditions-kernel-4.14.13-desktop-1.mga6-5.2.6-1.mga6.x86_64.rpm vboxadditions-kernel-4.14.13-server-1.mga6-5.2.6-1.mga6.x86_64.rpm vboxadditions-kernel-desktop-latest-5.2.6-1.mga6.x86_64.rpm vboxadditions-kernel-server-latest-5.2.6-1.mga6.x86_64.rpm virtualbox-5.2.6-1.mga6.x86_64.rpm virtualbox-devel-5.2.6-1.mga6.x86_64.rpm virtualbox-guest-additions-5.2.6-1.mga6.x86_64.rpm virtualbox-kernel-4.14.13-desktop-1.mga6-5.2.6-1.mga6.x86_64.rpm virtualbox-kernel-4.14.13-server-1.mga6-5.2.6-1.mga6.x86_64.rpm virtualbox-kernel-desktop-latest-5.2.6-1.mga6.x86_64.rpm virtualbox-kernel-server-latest-5.2.6-1.mga6.x86_64.rpm x11-driver-video-vboxvideo-5.2.6-1.mga6.x86_64.rpm
Host hardware: E8400 3GHz. Intel Core2Duo, 8GB RAM, Intel graphics, wired Internet. Host system: 64-bit Mageia 6 Plasma. The host had already been used to test the Bug #22392 graphical stack updates, so they are installed. Updated an existing vbox 5.2.2 install with an existing Windows XP guest. Packages installed cleanly, after which the 5.2.6 extension pack was downloaded and installed using the vbox "check for updates" function. XP guest booted with no problems, and guest additions were downloaded and installed. Everything looks good. Created a new 32-bit Mageia 6 Plasma guest using the Classical iso. After getting the big wave of updates and rebooting, the 5.2.6 guest additions were installed, followed by the appropriate Bug #22392 packages, and rebooted yet again. Everything looks OK, but the guest seems sluggish. I suppose this is to be expected, due to the performance hits from the Meltdown mitigation. A more modern host processor might help. Giving a tentative OK for 64-bit on this hardware.
CC: (none) => andrewsfarm
On mga6-64 packages installed cleanly - virtualbox-5.2.6-1.mga6.x86_64 - virtualbox-kernel-4.14.13-desktop-1.mga6-5.2.6-1.mga6.x86_64 - virtualbox-kernel-desktop-latest-5.2.6-1.mga6.x86_64 proprietary extension pack updated cleanly vbox and client launched normally OK for mga6-64 on this system: Dell product: Precision Tower 3620 Mobo: Dell model: 09WH54 Card: Intel HD Graphics 530 CPU: Quad core Intel Core i7-6700 (-HT-MCP-) PC-BIOS (legacy) boot GPT partitions
CC: (none) => jim
on mga6-32 in a vbox VM packages installed cleanly: - vboxadditions-kernel-4.14.13-desktop-1.mga6-5.2.6-1.mga6.i586 - vboxadditions-kernel-desktop-latest-5.2.6-1.mga6.i586 - virtualbox-guest-additions-5.2.6-1.mga6.i586 - x11-driver-video-vboxvideo-5.2.6-1.mga6.i586 VM rebooted normally no regressions noted Unlike reported in comment#1 the guest does not seem to be particularly sluggish The host has CPU Quad core Intel Core i7-6700 and the guest has 4GB of RAM (3.5GB of which is recognised by the desktop kernel) OK for mga6-32 in a vbox VM
@TJ if you have more than one CPU enabled in your mga6-32 guest, then reduce it to just one. My experience is that if you enable more than one CPU, the guest performance is significantly reduced, as it tries (and fails) to activate the additional CPU(s) Interestingly, my win7 guest does not have that problem.
I used the defaults, except that I told it to use 2GB of RAM (out of 8 total on the system), and that included only one CPU. My 32-bit XP guest shows no sluggishness, either. I now believe the sluggishness stems from my choice to use Plasma. It is the Plasma apps that are sluggish, at least in response to the mouse. System apps like MCC are fine. Disabling desktop effects by not starting the compositor on start-up made things a bit better. I have no benchmarks to use for comparison, but it has always seemed like 32-bit Plasma on 64-bit hardware has never felt quite as, um, efficient as the 64-bit version is. In any case, were I able to edit my comments here on Bugzilla, I would probably withdraw the part about the sluggishness.
Question: After installing the above 5.2.6 update, I found that I had to go to the virtualbox website to get the extension pack. While there, I saw this: "Important: The Guest Additions which come with VirtualBox 5.2.6 and 5.1.32 do not work properly on Linux guests with 3D enabled. Here are updated versions for 5.2.6 and 5.1.32." Are the guest additions we are providing the original ones for 5.2.6, or the updated ones?
Host: Athlon X2 7750 processor, 8GB RAM, Geforce 9800GT video, Atheros wifi, on a 64-bit Mageia6 Plasma install using the 4.14.13 server kernel. Guest: Mageia 6 64-bit Plasma, created with virtualbox 5.2.2. The nvidia340 driver of the host had already been updated to version 340.306 from the testing repositories. Packages installed cleanly. Upon starting, I discovered that the extension pack had to be downloaded from the virtualbox website. It installed with no problems. The Mageia 6 guest booted easily. After getting some waiting updates, I updated just the guest additions, and rebooted. I tired several apps, one of which was Klondike in Kpatience, running in demo mode. Everything looked good. I then went back after the updates for Bug #22392, and again rebooted, after which I again played Klondike in demo mode. This time, movement of the cards was slightly, yet noticeably, jerkier. Definitely not enough to make it unusable, just enough to notice.
(In reply to Thomas Andrews from comment #6) > > > Are the guest additions we are providing the original ones for 5.2.6, or the > updated ones? The original 5.2.6 as we dont have access to the newer source code yet...
Installed and tested without issues. Host system: Mageia 6, Plasma DE, x86_64, Intel CPU, nVidia GPU with nvidia340 proprietary driver. Guest systems: - Windows XP/7/10 - KDE neon - Mageia 6, Plasma DE, x86_64, 4.14.13-desktop-1.mga6 (booting this kernel was freezing virtualbox, one issue resolved) - Easy2Boot (only booting was tested) Tests included booting, installing updates and virtualbox guest additions, rebooting, running firefox and viewing a youtube video. $ uname -a Linux marte 4.14.13-desktop-1.mga6 #1 SMP Wed Jan 10 12:48:53 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ rpm -qa | egrep 'virtualbox|vbox' | sort dkms-virtualbox-5.2.6-1.mga6 virtualbox-5.2.6-1.mga6 virtualbox-doc-5.1.30-1.mga6 virtualbox-kernel-4.14.10-desktop-1.mga6-5.2.2-5.mga6 virtualbox-kernel-4.14.13-desktop-1.mga6-5.2.6-1.mga6 virtualbox-kernel-desktop-latest-5.2.6-1.mga6
CC: (none) => mageia
In VirtualBox, M6, Plasma, 64-bit Package(s) under test: virtualbox install from update testing: kernel-desktop-latest virtualbox vboxadditions-kernel-desktop-latest dkms-virtualbox virtualbox-guest-additions virtualbox-kernel-desktop-latest x11-driver-video-vboxvideo kernel-desktop-devel-latest dkms-nvidia-current [wilcal@localhost ~]$ uname -a Linux localhost 4.14.13-desktop-1.mga6 #1 SMP Wed Jan 10 12:48:53 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux [root@localhost wilcal]# urpmi kernel-desktop-latest Package kernel-desktop-latest-4.14.13-1.mga6.x86_64 is already installed [root@localhost wilcal]# urpmi virtualbox Package virtualbox-5.2.6-1.mga6.x86_64 is already installed [root@localhost wilcal]# urpmi vboxadditions-kernel-desktop-latest Package vboxadditions-kernel-desktop-latest-5.2.6-1.mga6.x86_64 is already installed [root@localhost wilcal]# urpmi dkms-virtualbox Package dkms-virtualbox-5.2.6-1.mga6.noarch is already installed [root@localhost wilcal]# urpmi virtualbox-guest-additions Package virtualbox-guest-additions-5.2.6-1.mga6.x86_64 is already installed [root@localhost wilcal]# urpmi virtualbox-kernel-desktop-latest Package virtualbox-kernel-desktop-latest-5.2.6-1.mga6.x86_64 is already installed [root@localhost wilcal]# urpmi x11-driver-video-vboxvideo Package x11-driver-video-vboxvideo-5.2.6-1.mga6.x86_64 is already installed [root@localhost wilcal]# urpmi kernel-desktop-devel-latest Package kernel-desktop-devel-latest-4.14.13-1.mga6.x86_64 is already installed [root@localhost wilcal]# urpmi dkms-nvidia-current Package dkms-nvidia-current-384.111-1.mga6.nonfree.x86_64 is already installed [wilcal@localhost ~]$ lspci -k 01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 440] (rev a1) Subsystem: Gigabyte Technology Co., Ltd Device 3518 Kernel driver in use: nvidia Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia_current Mageia-6-LiveDVD-Plasma-x86_64-DVD.iso md5sum: 1a152fb3aa5402761688d8aab67ae8df date: 7/11/17 M6 x86_64 Plasma LiveDVD runs as a Vbox client. Boots to a working desktop. Common apps work. Screen sizes are correct. Mageia-6-LiveDVD-Plasma-x86_64-DVD.iso md5sum: 1a152fb3aa5402761688d8aab67ae8df date: 7/11/17 M6 x86_64 Plasma LiveDVD installs and runs as a Vbox client. Boots to a working desktop. Common apps work. Screen sizes are correct. Mageia-6-LiveDVD-Plasma-x86_64-DVD.iso md5sum: 1a152fb3aa5402761688d8aab67ae8df date: 7/11/17 M6 x86_64 Plasma LiveDVD installed and then updated ( 332 files ). Boots to a "booting the kernel" hang screen. Screen shot attached. Test platform: Intel Core i7-2600K Sandy Bridge 3.4GHz GIGABYTE GA-Z68X-UD3-B3 LGA 1155 MoBo GIGABYTE GV-N440D3-1GI Nvidia GeForce GT 440 (Fermi) 1GB RTL8111/8168B PCI Express 1Gbit Ethernet DRAM 16GB (4 x 4GB) Mageia 6 64-bit, Nvidia driver Linux 4.14.13-desktop-1.mga6 x86_64
CC: (none) => wilcal.int
Created attachment 9913 [details] Booting the kernal hang screen
Same install as Comment 10 In VirtualBox, M6, Xfce, 32-bit Mageia-6-LiveDVD-Xfce-i586-DVD.iso md5sum: 911088471ddc24bc2d92084e19cec534 date: 7/11/17 M6 i586 Xfce LiveDVD runs as a Vbox client. Boots to a working desktop. Common apps work. Screen sizes are correct. Mageia-6-LiveDVD-Xfce-i586-DVD.iso md5sum: 911088471ddc24bc2d92084e19cec534 date: 7/11/17 M6 i586 Xfce LiveDVD installs runs as a Vbox client. Boots to a working desktop. Common apps work. Screen sizes are correct. Mageia-6-LiveDVD-Xfce-i586-DVD.iso md5sum: 911088471ddc24bc2d92084e19cec534 date: 7/11/17 M6 i586 Xfce LiveDVD installed and then updated ( 267 files ). Boots to a working desktop. Common apps work. Screen sizes are correct.
We clearly have a problem here. I'm not sure if it's Vbox or the recent kernel updates or Plasma. But I cannot do a new clean new install of x86_64 Plasma as a Vbox client then update it, that boots to a hang screen. Comment 10. Where I can go through the same process with an i586 Xfce, it installs, updates and reboots back to a working desktop just fine. Comment 12.
(In reply to William Kenney from comment #11) > Created attachment 9913 [details] > Booting the kernal hang screen Try booting using the failsafe boot option in grub. The output is more verbose with the failsafe boot and should give a better indication of where the boot hangs.
OK, Bill, I'm not seeing this on my machines. It doesn't act like a hardware problem to me, nor does it look like a conflict with nvidia. So let me look down through Comment 10 and see what's different... First of all, I see you have guest additions and the vboxvideo driver installed on the host. I don't. It's always been my understanding that while it shouldn't be a problem if they are on the host, they only need to be installed in the guests. Not likely to be the problem, but something to consider. Next, I don't see where you downloaded and installed the 5.2.6 extension pack. That's the first thing I do, even before trying out any existing guests to see if they still work. I would think that might be doubly important with the 4.14 kernels, and I would think that sddm might be touchier about that than other DMs might be. Did you forget to do that, or did you just not note it in your comment? The only other difference I see is that you installed from the LiveDVD iso, where I used the Classical. But, you only had a problem after getting the updates, so that really shouldn't be where the trouble lies. What other differences could there be?
On an HP Probook 6550b, Intel i3, 8GB RAM, integrated Intel graphics, Intel wifi, 64-bit Plasma install. Updated the following packages: - virtualbox-5.2.6-1.mga6.x86_64 - virtualbox-kernel-4.14.13-desktop-1.mga6-5.2.6-1.mga6.x86_64 - virtualbox-kernel-desktop-latest-5.2.6-1.mga6.x86_64 Packages installed cleanly, as did the 5.2.6 extension pack. I created a Mageia 6 Plasma virtual install using a LiveDVD iso dated June 6, 2017. The first boot went normally, after which I went after updates - over 518 packages! It took them a while, with two passes to get the full main set, but all installed cleanly. I then rebooted, removing "splash quiet" from the kernel options. The boot proceeded, eventually settling in with a message that four "start jobs" were running. Something to do with udev and initialization. Each job showed a time limit, one of which was a bit over nine minutes. I let it go, and eventually the boot completed. After updating the guest additions from Testing, I booted again, again without "splash quiet." This time the boot proceeded normally, and finished in a normal amount of time. Had I not edited the kernel options, and nothing about these "start jobs" showed on the screen, it would have been easy within those 9+ minutes to believe the boot had hung up. Perhaps, if Bill had just waited it out, his second boot would have eventually finished, too. I did not see an exceptionally long delay like that when installing from the Classical iso. The second boot WAS longer than normal, but not THAT long.
I used the June 6 iso because that's the one that was handy on the machine. Going now to download the official one...
Created attachment 9915 [details] booting the kernel hang verbose at hang
(In reply to William Kenney from comment #18) > Created attachment 9915 [details] > booting the kernel hang verbose at hang This is where it hung at .
(In reply to Thomas Andrews from comment #16) > I then rebooted, removing "splash quiet" from the kernel options. The boot > proceeded, eventually settling in with a message that four "start jobs" were > running. Something to do with udev and initialization. Each job showed a > time limit, one of which was a bit over nine minutes. I let it go, and > eventually the boot completed. Now that's something I'v never done, let it just go ( 9 minutes ) till it completes. Note, Saturday, 20 Jan I am pulling down my big i7 box and packing it for my move. Figure at least a week before I get back up again. As I don't see this as a complete show stopper we need to find the root cause of this. A nine minute 1st boot cycle is not acceptable.
So I let this cook for over an hour and it never came out of the hang screen.
I've seen the guest hang at that point if I had more than one CPU enabled in the guest. Reducing to just one CPU enabled in the guest resulted in it starting normally.
(In reply to James Kerr from comment #22) > I've seen the guest hang at that point if I had more than one CPU enabled in > the guest. Reducing to just one CPU enabled in the guest resulted in it > starting normally. James you are the best. I simply changed the number of CPU's in the client settings from 2 to 1 and the client booted up just fine. It then installed all the latest updates and rebooted again to a: Boots to a working desktop. Common apps work. Screen sizes are correct. Clearly there's a problem here. I don't think it should hold this bug up but we've got to at least find out if this is a Kernel, Vbox or nvidia problem. I'm less inclined to think it has anything to do with nvidia now. So as I have shared with everyone I am moving over the next week and will be packing all my everything. I hope to be back on line for communication a week from today and back testing again sometime during the week of 28 Jan. Have fun with this. :-))
(In reply to William Kenney from comment #23) > Clearly there's a problem here. I don't think it should hold this bug up but > we've got to at least find out if this is a Kernel, Vbox or nvidia problem. This is bug 21553.
Advisory, added to svn: type: security subject: Updated virtualbox packages fix security vulnerabilities CVE: - CVE-2017-3736 - CVE-2017-5715 - CVE-2018-2676 - CVE-2018-2685 - CVE-2018-2686 - CVE-2018-2687 - CVE-2018-2688 - CVE-2018-2689 - CVE-2018-2690 - CVE-2018-2693 - CVE-2018-2694 - CVE-2018-2698 src: 6: core: - kmod-vboxadditions-5.2.6-1.mga6 - kmod-virtualbox-5.2.6-1.mga6 - virtualbox-5.2.6-1.mga6 description: | Oracle VM VirtualBox incorporate the OpenSSL software libraries to provide cryptographic capabilities. OpenSSL versions through 1.0.2m and 1.1.0g are susceptible to a vulnerability that could allow an attacker to recover encryption keys and access protected communications (CVE-2017-3736). Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis (CVE-2017-5715). Oracle VM VirtualBox prior to 5.2.6 has easily exploitable vulnerabilities that allows high privileged attacker with logon to the infrastructure where VirtualBox executes to compromise it. While the vulnerability is in VirtualBox, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of VirtualBox (CVE-2018-2676). Oracle VM VirtualBox prior to 5.2.6 has easily exploitable vulnerabilities that allows unauthenticated attacker with logon to the infrastructure where VirtualBox executes to compromise it. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in VirtualBox, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of VirtualBox (CVE-2018-2685, CVE-2018-2686, CVE-2018-2687, CVE-2018-2688, CVE-2018-2689, CVE-2018-2690). Oracle VM VirtualBox Guest Additions prior to 5.2.6 has an easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where VirtualBox executes to compromise it. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in VirtualBox, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of VirtualBox (CVE-2018-2693). Oracle VM VirtualBox prior to 5.2.6 has easily exploitable vulnerabilities that allows low privileged attacker with logon to the infrastructure where VirtualBox executes to compromise it. While the vulnerability is in VirtualBox, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of VirtualBox (CVE-2018-2694, CVE-2018-2698). For other fixes in this update, see the referenced changelog. references: - https://bugs.mageia.org/show_bug.cgi?id=22408 - http://www.oracle.com/technetwork/security-advisory/cpujan2018-3236628.html#AppendixOVIR - https://www.virtualbox.org/wiki/Changelog
Keywords: (none) => advisory
installed on Intel laptop. mga5-32-bit Able to spin up 32 bit mate client after update. Host is running 4.14.13-desktop Working as designed so far. REgards, brian
CC: (none) => brtians1
Updated from 5.2.2 to 5.2.6 on Mageia 6::x86_64. Four vdis, representing two 32-bit Mageia guests, and two 64-bit. All booted fine and run normally.
CC: (none) => tarazed25
Blocks: (none) => 22454
validating as per QA meeting
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugsWhiteboard: (none) => MGA6-64-OK, MGA6-32-OK
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0101.html
Status: NEW => RESOLVEDResolution: (none) => FIXED