VirtualBox On Linux Affected By Security Vulnerability Leaking Host Data To Guests

[phoronix]

Phoronix: VirtualBox On Linux Affected By Security Vulnerability Leaking Host Data To Guests

Security researcher Jason Donenfeld who is known for leading the development of the WireGuard open-source software has outlined a new security vulnerability affecting the Oracle VM VirtualBox software...

https://www.phoronix.com/scan.php?pa...-Host-To-Guest

[CochainComplex]

virtualborx (sic) bug sounds cool

[cbxbiker61]

I have been gradually migrating from virtualbox to libvirt/qemu. Win11 seems to work fine under libvirt, even usb pass-through works for my Haltech ECU.

[CochainComplex]

I have been gradually migrating from virtualbox to libvirt/qemu. Win11 seems to work fine under libvirt, even usb pass-through works for my Haltech ECU.

i did the same for some vagrant machines.

[Quackdoc]

the time of vbox is over IMO, everyone is moving on to either vmware or qemu, it's a shame qemu doesn't have 3d accel for windows guests. it would be the almost perfect solution in that case

[polarathene]

I have been gradually migrating from virtualbox to libvirt/qemu. Win11 seems to work fine under libvirt, even usb pass-through works for my Haltech ECU.

Main issue with QEMU I have is UEFI guests and snapshot support. This was recently fixed in QEMU I think, but the developer stated fixing support in libvirt was much more complicated and wouldn't arrive any time soon..

Other than that, I'm interested in lightweight 3D accel for guests to leverage desktop compositing without llvmpipe... virgl/venus seems to be able to cater to that, but at least on nvidia the overhead is looking massive (10% of host score for Unigine Heaven, 5-10% glmark2, or <1% glmark2 if using egl-headless if spice is handling the display).

I'm also interested in HW decode for video support, which I don't know if any hypervisor offering provides, but I'm hopeful with Venus providing Vulkan on host support, that Vulkan Video API may eventually be viable for this... VMware seems to be embracing Vulkan for 3D accel guests on linux hosts, so it might be something they're considering too.

Sadly, VMware linux apps (at least VMPlayer) seems to be spotty with support for display management (at least on Arch KDE and Fedora 36 Gnome, there's no multi-monitor or viewport controls visible).. While a paid proprietary product, I don't get the impression that linux support gets as much attention from looking over bug reports and history recently. They also have a bug (at least with `open-vm-tools` which is encouraged on linux guests instead of VMware Tools), where if you copy a file on either host or guest, when it's the active clipboard item, it'll be copied over to the other side (guest or host) once the mouse crosses that boundary, separate from Drag'n'Drop feature (but copies to the same location).

I guess it depends on your needs, QEMU + libvirt is almost there for me (but progress on issues I have may take another year or so AFAIK). I'd be happy to pay for a VMware Workstation license if it provided the advertised functionality without horrendous bugs that QA should be able to catch. Just as happy to pay open-source devs, but the same money isn't going to be enough make faster progress happen on those issues.

the time of vbox is over IMO, everyone is moving on to either vmware or qemu, it's a shame qemu doesn't have 3d accel for windows guests. it would be the almost perfect solution in that case

I imagine once Venus support is more mature (and available for QEMU?) we might see some progress on that? At least with all the work MS has been doing with WSL, you'd think they might be interested in similar support on their OS? I guess they've done similar for mesa in WSL to route to DX12, and running Windows guests on Linux hypervisors may be less interesting to them for a DX12/Vulkan virglrenderer driver to be supported? RedHat might get some collaboration going there though due to the current experience/efforts from MS with WSL and mesa?

That or VMware open-source something compatible on their end. They can support 3D accel with Windows and Linux guests, which on Linux hosts routes to Vulkan since the 16 series release (which includes OpenGL to Vulkan). I could see some interest maybe in collaborating with Mesa like they do with current SVGA mesa driver (which is getting a refactor to use Vulkan) to leverage Venus? Then maybe you could just install VMware tools display driver in a Windows guest and have that route to linux host virglrender to handle like Venus?

[sophisticles]

The reality is that most, if not all, software that is any more complex than a simple class project probably has some security vulnerability, it's the nature of writing software.

Very few people are capable of writing clean, well thought out software and that includes OSS developers, people are lazy and look for shortcuts in coding and you end up with poorly structured code that can be exploited.

[Quackdoc]

Main issue with QEMU I have is UEFI guests and snapshot support. This was recently fixed in QEMU I think, but the developer stated fixing support in libvirt was much more complicated and wouldn't arrive any time soon..

this is a pain for me too lol

Other than that, I'm interested in lightweight 3D accel for guests to leverage desktop compositing without llvmpipe... virgl/venus seems to be able to cater to that, but at least on nvidia the overhead is looking massive (10% of host score for Unigine Heaven, 5-10% glmark2, or <1% glmark2 if using egl-headless if spice is handling the display).

virgl has massive preformance overhead, it's not just nvidia.

I'm also interested in HW decode for video support, which I don't know if any hypervisor offering provides, but I'm hopeful with Venus providing Vulkan on host support, that Vulkan Video API may eventually be viable for this... VMware seems to be embracing Vulkan for 3D accel guests on linux hosts, so it might be something they're considering too.

crosvm has virtio-video no word about virtio-video getting ported to qemu

I imagine once Venus support is more mature (and available for QEMU?) we might see some progress on that? At least with all the work MS has been doing with WSL, you'd think they might be interested in similar support on their OS? I guess they've done similar for mesa in WSL to route to DX12, and running Windows guests on Linux hypervisors may be less interesting to them for a DX12/Vulkan virglrenderer driver to be supported? RedHat might get some collaboration going there though due to the current experience/efforts from MS with WSL and mesa?

it's possible, the process I foresee being the path of least resistance is to venus for guest drivers, d3d10umd over zink for general desktop acceleration then using DXVK for everything else. doesn't seem like we will be getting qemu venus any time soon sadly.

That or VMware open-source something compatible on their end. They can support 3D accel with Windows and Linux guests, which on Linux hosts routes to Vulkan since the 16 series release (which includes OpenGL to Vulkan). I could see some interest maybe in collaborating with Mesa like they do with current SVGA mesa driver (which is getting a refactor to use Vulkan) to leverage Venus? Then maybe you could just install VMware tools display driver in a Windows guest and have that route to linux host virglrender to handle like Venus?

the d3d10umd driver is the vmware software driver that they use for cpu rendering. it's worth noting that d3d11umd is an extension to that so d3d11 support could be achieved too. the issue is that d3d10umd would need some work done to get it to work with zink or virgl. really either would be fine, since we can use dxvk for the graphics of individual apps if vulkan guest support existed.

[linuxgeex]

I'm also interested in HW decode for video support, which I don't know if any hypervisor offering provides, but I'm hopeful with Venus providing Vulkan on host support, that Vulkan Video API may eventually be viable for this... VMware seems to be embracing Vulkan for 3D accel guests on linux hosts, so it might be something they're considering too.

AFAIK the only way to get VAAPI is to use hardware passthrough. As luck would have it, that provides pretty good Vulkan/OpenGL as well ;^) but if you only have one GPU and you were planning to virtualise it across multiple boxen, then you're better off doing your video processing on the host node. If that means you can't run FinalCutPro on your Hackintosh... well... today an M1 Mac Mini costs less than a decent GPU, so you're probably best off to just get the Mac.

[polarathene]

virgl has massive preformance overhead, it's not just nvidia.

I've seen reports of much better scores, but without equivalent hardware I can't reproduce. Even this blog post from Sep 2020 shows a user getting 80% performance, that's huge compared to the 10% or less I get with nvidia 1070 (which managed 60% of the host score with VMware Player). They used an AMD RX580.

There was another interesting insight in this forum thread, which used an AMD 6700XT, but only benched with glmark2 which I've found generally performs worse vs other benchmarks such as Unigine Heaven. So keep that in mind regarding their findings. I've noticed host GPU usage for glmark2 on my 1070 only being around 20-30%, so I could add more instances like they did, it's just considerable overhead that is the issue. Unigine Heaven uses 100% of the host GPU despite performing at 10%, so no artificial cap to performance there.

Possibly due to framerate differences if it's copying the frames via CPU for display as an OpenGL texture in the windowed view of the guest? Glmark2 while being twice as good on VMware (still around 5-6x worse than host) and the much better Unigine Heaven performance might hint towards displaying frames (and their size) being a performance killer more than the processing by GPU to render the actual frames.

If so, Wayland might be able to better workaround that I think? It may also explain why the Intel iGPU was performing very close to host compared to nvidia 1070. If frames are being transferred from vRAM to RAM (and back to vRAM for OpenGL display?). I'll look into that further, I assume Venus can workaround that with Vulkan as I hear the memory management is quite different (and more involved/complicated), perhaps it skips that possible bottleneck to keep performance closer to native/host.

I'm not interested in gaming in such guests, but I would appreciate getting 50% of host performance at the very least. It seems that that's possible with AMD, and I know nvidia can do it with VMware. So definitely improvement for virgl, but maybe VMware is doing well due to Vulkan backend (I didn't try it prior to that switch).

UPDATE:

Confirmed that PCIe bandwidth utilization is high. VM with virgl is 80% and stays like that while unigine-heaven is running, despite lowering window resolution or graphic settings. FPS improved very slightly, from around 12 to 15, final score from around 320 to 360, max FPS reached 37 (about 6 better than extreme preset). GPU utilization (actual rendering, not PCIe transfers between GPU and CPU) was always at 100%. CPU usage was not a bottleneck. Didn't seem to make a difference between X11 or Wayland guest (X11 host), probably because it would have run in XWayland.

VMware Player was easily managing 60 FPS and without vsync putting a full CPU core to use when hitting 100+ FPS (10x than virgl) at lowest settings and resolution. GPU utilization was averaging around 50% (host was averaging 30%) and PCIe bandwidth utilization around 15-20% (basically same as host). Score was about average 95 FPS, max about 200, score ~2500. Host benched 170 average FPS max 280 and score of ~4200.

Even on the extreme preset with vsync off (GPU utilization at 100%), VMware kept a lower PCIe bandwidth utilization around 20%. So virgl was generating 4x the bandwidth/traffic through PCIe (x16 3.0). It'd be interesting to know how well Zink in the guest paired with Venus would compare to VMware, hopefully someone with the skills to push Venus with QEMU forward will be able to get that functional

crosvm has virtio-video no word about virtio-video getting ported to qemu

I assume that's similar to what MS did with that recent WSL article for VA-API to DX12? That'd be cool to pass VA-API from guest to host via `virtio-video`, but I would assume that we'd get similar for free with Venus support (assuming Vulkan Video extensions are available/working on host driver, nvidia has experimental support presently that MPV devs have been testing out).

VMware might have some more weight to push for Vulkan Video support with their own Vulkan backend on Linux hosts, and as they're already mapping DX12 to Vulkan in that case, they'd probably opt for that route for video encode/decode via Vulkan Video than implementing `virtio-video` or similar? I'm happy with whatever gets better supported, but can see Vulkan Video perhaps being easier to integrate/support cross-platform?

doesn't seem like we will be getting qemu venus any time soon sadly.

When I saw the Collabora blog post about QEMU Venus support in Nov 2021, it looked hopeful.. But the QEMU patches mailing list discussion seemed to not be interested due to dependency upon virglrenderer version requirement at the time being too new and that at best they'd offer support behind a compile flag or something, with the expectation that it'd take 2 years or so before they'd be comfortable enabling it by default. I haven't seen any further progress on that front though sadly (not great at navigating mailing list vs Gitlab/Github activity).

I didn't bother trying to manually apply the patches from the blogpost myself to try Venus out. Virglrenderer project continues to get work on Venus, so it might be interesting to know how well it'd work, at the same time I'm worried about the patches breaking over time as the developer doesn't seem to rebase them (I have no idea how to follow the status of patches and if any feedback was addressed).

the d3d10umd driver is the vmware software driver that they use for cpu rendering.
the issue is that d3d10umd would need some work done to get it to work with zink or virgl.

I think we're talking about different things? I know Mesa has the VMware SVGA drivers, and that VMware open-sourced some gallium state tracker as well for D3D10. They had mentioned that adding D3D11 support would be minimal effort, but they were not going to pursue that as they were shifting to there Vulkan backend. The open-sourced drivers can be leveraged by VirtualBox and QEMU AFAIK for display, but they lack 3D accel don't they?

I was referring to closed-source portion, that VMware has with their own product that provides the much better 3D accel performance than virgl. I understand prior to Workstation 16, they used OpenGL drivers on linux hosts, but have since switched to Vulkan on the host for rendering whatever 3D accel the guest needs? I'm not entirely sure of the relation between those proprietary components and the open-source ones, but if the guest portion is open-source, and that resulted in usable Windows drivers similar to linux guests sharing a common backend on Linux hosts through mesa (instead of whatever VMware presently is doing), perhaps the work with virglrenderer/Venus would allow for something like that?

At least from what I'm seeing Google is using virglrenderer with their own alternatives to Venus being added to meet their needs. But maybe making that more available when there isn't much competition from QEMU and VirtualBox would be a financial incentive not to collaborate