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
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
