Nixpkgs: VirtualBox cannot access OpenGL with Nvidia Drivers as Normal User

[nihil-2019]

Issue description

Exactly as it says in the title. VirtualBox cannot access OpenGL with Nvidia Drivers as Normal User, Which Prevents {2,3}D Acceleration From Working.

LIBGL_DEBUG=verbose VirtualBox
libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /run/opengl-driver/lib/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /run/opengl-driver/lib/dri/swrast_dri.so
libGL: dlopen /run/opengl-driver/lib/dri/swrast_dri.so failed (/run/opengl-driver/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory)
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast

Every other opengl program on the system works fine (Ironically enough, even VBoxOGLTest, which VirtualBox itself uses to test for OpenGL support, works fine.) , glxinfo reports the right values, etc; So I am certain the issue is isolated to VirtualBox.

This does not happen when executing the real, non setuid-wrapper, VirtualBox executable, which obviously requires root. When launched this way, it exhibits normal behavior. However, obviously launching a program as root is not an acceptable workaround.

Steps to reproduce

1. Execute VirtualBox as non-root user, either from terminal or desktop file.

Technical details

• System: 17.03pre100821.6651c72 (Gorilla)
• Nix version: 1.11.6
• Nixpkgs version: 17.03pre100821.6651c72

[vcunat]

Ah, I broke that one, probably, though it was after the nixpkgs/nixos version that you list. Quick workaround. I thought I have fixed it later by 31eba21d, though I might've missed something.

[nihil-2019]

@vcunat Thanks for replying to my issue, however, it looks like the fix & workaround you're linking refers to a guest VM using the VirtualBox opengl driver from Virtualbox Guest Additions. In that case, unless I'm really misunderstanding something, I don't think it relates to this issue.

You see, I'm not using the VirtualBox Guest Additions package at all. I am using VirtualBox on NixOS on a _host_ machine, using the nvidia drivers. Even if VirtualBox Guest Additions works fine on the guest VM, VirtualBox fails to pick up 2D/3D Acceleration from the host drivers, preventing it from working.

Also, again, everything works fine if you execute the real VirtualBox binary from /run/current-system/bin/, bypassing the setuid-wrapper, so I'm certain it has something to do with that, though I'm not quite sure how.

[abbradar]

It seems that you have Mesa drivers loaded instead for VirtualBox: notice that they try to load swrast -- can Nvidia do that? My current theory is that VirtualBox clears LD_LIBRARY_PATH somewhere.

[vcunat]

Could VirtualBox host side have some restrictions on xorg-server ABI (of the host)? (Assuming it all worked fine until now.)

[abbradar]

@cmason37 Could you run strace -e trace=file VirtualBox 2>trace.log and upload the result somewhere?

[nihil-2019]

@abbradar When I ran this, the terminal output [1] 15711 abort strace -e trace=file VirtualBox 2> /tmp/trace.log

It did succeed in generating a log, as shown here, however the log just shows VirtualBox failing to execute due to the SUID assertion failing, which I'm assuming is not supposed to happen.

Of course, Virtualbox still executes fine normally, albeit with this bug still in effect.

[abbradar]

I think I found the reason now, but I'm unsure how to proceed.

The core problem is that LD_LIBRARY_PATH is not supported in setuid wrappers, and that's by design -- otherwise one could run arbitrary code with elevated privileges. But this feature is a bit sledgehammer'y in that we can't even set LD_LIBRARY_PATH in setuid wrapper -- it'll still be ignored later by ld.so because getuid() != geteuid(). Effectively setuid programs can't use OpenGL now on NixOS.

Not sure how did this work before with VirtualBox. A quick specific workaround would be virtualization.virtualbox.host.enableHardening = false. Long-term we may want to use /etc/ld-nix.so.conf instead of LD_LIBRARY_PATH -- I have patches for this.

EDIT: ld-nix.so.conf won't actually help because its priority is lower than DT_RUNPATH (--set-rpath in patchelf) so the dynamic linker would prefer linked OpenGL libraries to system ones.

[abbradar]

I think the best course of action for now is to mention in documentation that OpenGL is broken with hardening and wait till Mesa supports GLVND. @cmason37, can you confirm that:

virtualization.virtualbox.host.enableHardening = false;
users.extraUsers.alice.extraGroups = [ "vboxusers" ];

, where "alice" is substituted by your username, fixes that for you?

[vcunat]

With GLVND there won't be any need for /etc/ld-nix.so.conf anymore, will there?

[abbradar]

@vcunat Yep, though ld-nix.so.conf won't help anyway because of priorities.

[vcunat]

Oh, actually, I'm not certain about libvdpau and maybe something else I've forgotten.

[abbradar]

Those use hardcoded mesa.driverLink to look for their drivers now so they should be okay. One exception that I remember is vulkan-loader which uses XDG data dirs (should be okay anyway).

[nihil-2019]

@abbradar Yes, this fixes the issue.

[jb55]

I'm hitting this issue on unstable (56fb68dcef494b7cdb3e09362d67836b8137019c).

I have the following in my config:

  virtualisation.virtualbox.host.enable = true;
  virtualization.virtualbox.host.enableHardening = false;
  users.extraUsers.jb55.extraGroups = [ "vboxusers" ];

Running LIBGL_DEBUG=verbose VirtualBox I get:

libGL: screen 0 does not appear to be DRI2 capable
libGL: OpenDriver: trying /run/opengl-driver/lib/dri/tls/swrast_dri.so
VirtualBox: supR3HardenedVerifyFileFollowSymlinks: Failed to resolve the real path '/run/opengl-driver/lib/dri/tls/swrast_dri.so': No such file or directory (2)
libGL: OpenDriver: trying /run/opengl-driver/lib/dri/swrast_dri.so
VirtualBox: supR3HardenedVerifyFileFollowSymlinks: Failed to resolve the real path '/run/opengl-driver/lib/dri/swrast_dri.so': No such file or directory (2)
libGL: dlopen /run/opengl-driver/lib/dri/swrast_dri.so failed ((null))
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast

and when attempting to enable hardware acceleration I see:

[devhell]

Is there any more insight on this? I'm hitting this issue too.

[Yarny0]

I'm seeing the same problem since the update to NixOS 18.09. However, I'm not using Nvidia, but (as of hwinfo):

Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller

The glxgears are rotating smoothly. As stated in the original report, even VBoxTestOGL --test 3D --log /dev/stdout gives me

Testing 3D Succeeded!

The command LIBGL_DEBUG=verbose VirtualBox didn't show any relevant output besides Qt complaining about "No XVisualInfo for format QSurfaceFormat".

This worked find for me in NixOS 18.03. While the sympoms are very similar I'm therefore not sure if my problem is the same that was reported here originally. So I can open a new issue if requested.

[chasevasic]

This issue is affecting me as wel on 18.09 with an nvidia card. I don't think it's actually related to the specific video drivers. I tried the VBoxTestOGL and got a success too. It's kind of a nightmare trying to hunt down what's happening with strace.

[thorstenweber83]

same here: i'm running NixOS on a latitude 5495 with vega graphics. VBoxTestOGL is successful and directly running the VirtualBox binary as root also shows working Acceleration.

[flokli]

@abbradar @vcunat from my understanding, mesa in nixpkgs should support GLVND by now - however, 3d acceleration still seems to be broken, regardless of whether hardening is enabled or not. Any ideas?

[vcunat]

The default libGL that everyone should link against is just a glvnd stub now.

[ambrop72]

I have a fix for this in the works. It is by patching the libglvnd libraries to include /run/opengl-driver/lib in their RUNPATH. But it's a mass rebuild so it will take some time until I can test.