[vbox-dev] BLUF: Consider enabling 3D acceleration by default (as least for KDE-based Linux guest OSs)

[Klaus Espenlaub]

Hello Aaron,

see inline...

On 2024-03-08 19:20, Aaron Rainbolt via vbox-dev wrote:
> On 3/8/24 11:24, Aaron Rainbolt wrote:
>> On 3/8/24 11:10, Nate Graham via vbox-dev wrote:
>>> Hello! I'm Nate Graham from KDE. We're tracking an issue that causes 
>>> Linux guest OSs with KDE Plasma 6 to fail when 3D acceleration is 
>>> disabled: https://bugs.kde.org/show_bug.cgi?id=481937. The changes 
>>> made in Plasma 6 that resulted in this issue are unfortunately not 
>>> easily revertable, and 3D acceleration improves the UX in general 
>>> for our systems, so our developers aren't feeling a strong incentive 
>>> for to try.
>>>
>>> I'd like to discuss the possibility of enabling 3D acceleration by 
>>> default--at least for as least for KDE-based Linux guest OSs.
>>
>> I am not a VBox dev, but this change has potentially severe security 
>> implications that would make me highly uncomfortable enabling this if 
>> I were a VBox dev. Quoting from the VirtualBox 7.0 user manual 
>> (https://docs.oracle.com/en/virtualization/virtualbox/7.0/user/guestadditions.html#guestadd-video):
>>
>> Note:
>>
>> Untrusted guest systems should not be allowed to use the 3D 
>> acceleration features ofOracle VM VirtualBox, just as untrusted host 
>> software should not be allowed to use 3D acceleration. Drivers for 3D 
>> hardware are generally too complex to be made properly secure and any 
>> software which is allowed to access them may be able to compromise 
>> the operating system running them. In addition, enabling 3D 
>> acceleration gives the guest direct access to a large body of 
>> additional program code in theOracle VM VirtualBoxhost process which 
>> it might conceivably be able to use to crash the virtual machine.
>>
The newer 3D architecture we're using in VirtualBox for a while should 
make this less serious and less likely, but it's a lot of new code and 
therefore the risk is certainly non-zero.

>> If KDE-based Linux VMs have 3d acceleration become mandatory, 
>> KDE-based Linux VMs will also no longer be suitable for any 
>> security-sensitive use of VirtualBox (malware analysis, sandboxing of 
>> suspicious applications, etc.). The ability for VirtualBox to sandbox 
>> insecure software is important enough that the guide specifically 
>> mentions it as a primary use case for VirtualBox 
>> (https://docs.oracle.com/en/virtualization/virtualbox/7.0/user/Introduction.html#virtintro):
>>
>> In addition to that, with the use of anotherOracle VM 
>> VirtualBoxfeature calledsnapshots, one can save a particular state of 
>> a virtual machine and revert back to that state, if necessary. This 
>> way, one can freely experiment with a computing environment. If 
>> something goes wrong, such as problems after installing software or 
>> infecting the guest with a virus, you can easily switch back to a 
>> previous snapshot and avoid the need of frequent backups and restores.
>>
>> It would help to know what exactly these changes are that "cannot be 
>> easily reverted" (probably not on the VBox ML though). Perhaps 
>> someone who is willing to put in the necessary time and effort can 
>> discover a way to make KWin compatible with more secure graphics 
>> options under VirtualBox? I personally would be willing to try and 
>> help with that.
>>
> So actually, as it turns out, this appears to be an issue with the 
> VMSVGA graphics controller in VirtualBox in particular. If I switch to 
> the VBoxSVGA controller instead, I can boot the latest KDE neon User 
> Edition ISO with Plasma 6 without 3d acceleration. It appears to work 
> just fine.
>
> Changing to VBoxSVGA graphics in an Ubuntu VM results in a warning in 
> VirtualBox stating "The virtual machine is configured to use a 
> graphics controller other than the recommended one (VMSVGA). Please 
> consider switching unless you have a reason to keep the currently 
> selected graphics controller." Is there a particular reason this is 
> still shown? Is VMSVGA even still a good default for Linux virtual 
> machines? I believe Windows virtual machines use VBoxSVGA by default, 
> and Linux appears to work with it, so perhaps it would help to simply 
> change the default graphics adapter for (at least some) Linux OSes.
>
Taking a deep breath... once upon a time there was just VBoxVGA, which 
needed a driver provided by VirtualBox Guest Additions (vboxvideo.ko) 
for good functionality. We had working 3D support for it even, however 
it was a never ending security nightmare due to the 3rd party codebase 
which was never meant to be used in a security sensitive context. So we 
decided to limit declare this device as legacy, dropping 3D support.

The new graphics device (VMSVGA) was added in VirtualBox 6 and is 
scheduled to take over completely, including 3D support. The reason: 
Linux already brings a kernel module with the full functionality 
(including 3D, ...) and VirtualBox provides the necessary device 
emulation - which still has its rough edges but we're working on 
resolving those. Annoyingly, the maintainer of vmwgfx.ko in the Linux 
kernel has recently added a message which is shown for users of 
VirtualBox, hinting that they should pick a supported device. Which is 
100% misleading, because the supported one from our point of view is VMSVGA.

So what's VBoxSVGA? That's a hybrid between VBoxVGA and VMSVGA which we 
invented primarily to ease the transition for Windows VMs. It offers the 
functionality of both devices under the PCI device ID of VBoxVGA. That 
way our Windows driver can go for the VMSVGA functionality (and if you 
didn't update the Guest Additions before updating VirtualBox the old 
driver would be using VBoxVGA functionality to provide at least basic 
functionality). The same also works with Linux, using purely the VBoxVGA 
part of the device through the - legacy - vboxvideo.ko. What you found 
is that going with this legacy device is a workaround. You could've 
switched directly to VBoxVGA to get the exact same result.

Bottom line: your finding hints that there's a compatibility issue 
between vmwgfx.ko and the VMSVGA implementation in VirtualBox. Something 
which we'd be willing to investigate, as soon as a developer in the 
VirtualBox team with enough graphics knowledge has time for it.

Klaus
>
> -- 
> Aaron Rainbolt
> Lubuntu Developer
> Matrix: @arraybolt3:matrix.org
> IRC: arraybolt3 on irc.libera.chat
> GitHub:https://github.com/ArrayBolt3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.virtualbox.org/pipermail/vbox-dev/attachments/20240309/d05c604b/attachment-0001.html>