GNU bug report logs - #72265
[PATCH 0/1] Fix hardware acceleration support for librewolf

Previous Next

To reply to this bug, email your comments to 72265 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nikita Domnitskii <nikita <at> domnitskii.me>
To: guix-patches <at> gnu.org
Subject: [PATCH 0/1] Fix hardware acceleration support for librewolf
Date: Wed, 24 Jul 2024 11:44:31 +0600

Current approach with LD_LIBRARY_PATH seems wrong for multiple reasons:
1. It doesn't work
2. It would require us to add all available drivers and every shared
library that drivers load

Currently it works like that:

--8<---------------cut here---------------start------------->8---
$ MOZ_SANDBOX_LOGGING=1 librewolf
libva info: Trying to open /run/current-system/profile/lib/dri/iHD_drv_video.so
[3323] Sandbox: SandboxBroker: denied op=open rflags=2000000 perms=0 path=/gnu/store/371amhgyc25i0frgxkllp94v6rvvyl0y-intel-media-driver-nonfree-24.1.5/lib/dri/iHD_drv_video.so for pid=3971
[3971] Sandbox: Failed errno -13 op open flags 02000000 path /run/current-system/profile/lib/dri/iHD_drv_video.so
[3323] Sandbox: SandboxBroker: denied op=access rflags=0 perms=0 path=/gnu/store/371amhgyc25i0frgxkllp94v6rvvyl0y-intel-media-driver-nonfree-24.1.5/lib/dri/iHD_drv_video.so for pid=3971
[3971] Sandbox: Failed errno -13 op access flags 00 path /run/current-system/profile/lib/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
--8<---------------cut here---------------end--------------->8---

If I'll add /run/current-system/profile/lib/dri to LD_LIBRARY_PATH it
tries to load gmmlib:

--8<---------------cut here---------------start------------->8---
$ MOZ_SANDBOX_LOGGING=1 LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/run/current-system/profile/lib librewolf
libva info: Trying to open /run/current-system/profile/lib/dri/iHD_drv_video.so
[5004] Sandbox: Failed errno -2 op open flags 02000000 path /gnu/store/z987j9j71l114051dg3722amqcnv84c6-librewolf-126.0-1/lib/librewolf/libigdgmm.so.12
[5004] Sandbox: Failed errno -2 op open flags 02000000 path /gnu/store/9i3zzv8kmv2rkkiyn70lp594fz637vna-mesa-24.0.4/lib/libigdgmm.so.12
... tries to lookup libigdgmm.so.12
[5004] Sandbox: Failed errno -2 op open flags 02000000 path /gnu/store/ln6hxqjvz6m9gdd9s97pivlqck7hzs99-glibc-2.35/lib/libigdgmm.so.12
libva error: dlopen of /run/current-system/profile/lib/dri/iHD_drv_video.so failed: libigdgmm.so.12: cannot open shared object file: No such file or directory
libva info: va_openDriver() returns -1
--8<---------------cut here---------------end--------------->8---

So I propose to use NixOS approach (already upstreamed) 

Nikita Domnitskii (1):
  gnu: librewolf: Add guix drivers paths to RDD whitelist

 gnu/packages/librewolf.scm                    | 20 ++++---------------
 ...librewolf-add-paths-to-rdd-whitelist.patch | 11 ++++++++++
 2 files changed, 15 insertions(+), 16 deletions(-)
 create mode 100644 gnu/packages/patches/librewolf-add-paths-to-rdd-whitelist.patch


base-commit: ee7e5e00bf2b9257e67d785b37efddb008c5da37


-- 
Best Regards,
Nikita Domnitskii

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nikita Domnitskii <nikita <at> domnitskii.me>
To: guix-patches <at> gnu.org
Subject: [PATCH 1/1] gnu: librewolf: Add guix drivers paths to RDD whitelist
Date: Wed, 24 Jul 2024 11:44:51 +0600

Change-Id: I5aaf590b625dfbacb19b6dc54d7f83f73bea1fda
---
 gnu/packages/librewolf.scm                    | 20 ++++---------------
 ...librewolf-add-paths-to-rdd-whitelist.patch | 11 ++++++++++
 2 files changed, 15 insertions(+), 16 deletions(-)
 create mode 100644 gnu/packages/patches/librewolf-add-paths-to-rdd-whitelist.patch

diff --git a/gnu/packages/librewolf.scm b/gnu/packages/librewolf.scm
index 3e46477724..b34e29d9db 100644
--- a/gnu/packages/librewolf.scm
+++ b/gnu/packages/librewolf.scm
@@ -203,7 +203,9 @@ (define librewolf-source
                (invoke "make" "all")
                (copy-file (string-append "librewolf-" #$version
                                          ".source.tar.gz")
-                          #$output))))))))
+                          #$output)))))
+      (patches
+       (search-patches "librewolf-add-paths-to-rdd-whitelist.patch")))))
 
 ;; Define the versions of rust needed to build librewolf, trying to match
 ;; upstream.  See the file taskcluster/ci/toolchain/rust.yml at
@@ -573,26 +575,12 @@ (define-public librewolf
                                        ;; For U2F and WebAuthn
                                        "eudev")))
 
-                              ;; VA-API is run in the RDD (Remote Data Decoder) sandbox
-                              ;; and must be explicitly given access to files it needs.
-                              ;; Rather than adding the whole store (as Nix had
-                              ;; upstream do, see
-                              ;; <https://github.com/NixOS/nixpkgs/pull/165964> and
-                              ;; linked upstream patches), we can just follow the
-                              ;; runpaths of the needed libraries to add everything to
-                              ;; LD_LIBRARY_PATH.  These will then be accessible in the
-                              ;; RDD sandbox.
-                              (rdd-whitelist (map (cut string-append <> "/")
-                                                  (delete-duplicates (append-map
-                                                                      runpaths-of-input
-                                                                      '("mesa"
-                                                                        "ffmpeg")))))
                               (gtk-share (string-append (assoc-ref inputs
                                                                    "gtk+")
                                                         "/share")))
                          (wrap-program (car (find-files lib "^librewolf$"))
                            `("LD_LIBRARY_PATH" prefix
-                             (,@libs ,@rdd-whitelist))
+                             (,@libs))
                            `("XDG_DATA_DIRS" prefix
                              (,gtk-share))
                            `("MOZ_LEGACY_PROFILES" =
diff --git a/gnu/packages/patches/librewolf-add-paths-to-rdd-whitelist.patch b/gnu/packages/patches/librewolf-add-paths-to-rdd-whitelist.patch
new file mode 100644
index 0000000000..1bee0bddf5
--- /dev/null
+++ b/gnu/packages/patches/librewolf-add-paths-to-rdd-whitelist.patch
@@ -0,0 +1,11 @@
+--- a/security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp
++++ b/security/sandbox/linux/broker/SandboxBrokerPolicyFactory.cpp
+@@ -920,6 +920,8 @@
+   policy->AddDir(rdonly, "/usr/lib64");
+   policy->AddDir(rdonly, "/run/opengl-driver/lib");
+   policy->AddDir(rdonly, "/nix/store");
++  policy->AddDir(rdonly, "/gnu/store");
++  policy->AddDir(rdonly, "/run/current-system/profile/lib");
+
+   // Bug 1647957: memory reporting.
+   AddMemoryReporting(policy.get(), aPid);


-- 
Best Regards,
Nikita Domnitskii

Message #11 received at 72265 <at> debbugs.gnu.org (full text, mbox):

From: Ian Eure <ian <at> retrospec.tv>
To: 72265 <at> debbugs.gnu.org, Nikita Domnitskii <nikita <at> domnitskii.me>
Subject: Re: [PATCH 0/1] Fix hardware acceleration support for librewolf
Date: Tue, 30 Jul 2024 17:12:39 -0700

Hello,

I’d like to have a better handle on *why* this isn’t working, and 
what alternate options may exist, before granting LW’s sandboxed 
processes full access to the store.  Since a lot of system config 
stuff ends up in there, and Guix doesn’t have a good way to manage 
secrets, it feels risky to me to open it up.

Do you have reproduction steps which demonstrate the issue?  I see 
it complaining about not loading libva, but setting 
`MOZ_LOG="PlatformDecoderModule:5"'[1] and enabling the various 
ffmpeg config bits, then playing a video, it *seems* like it’s 
using hwaccel.

The approach in LW is taken directly from the Firefox packages in 
Nonguix -- can you reproduce your problem with that packages? 
That might provide a clue as to what’s different between the two 
package definitions.

Thanks,

 — Ian

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1610199#c31

Message #14 received at 72265 <at> debbugs.gnu.org (full text, mbox):

From: Nikita Domnitskii <nikita <at> domnitskii.me>
To: Ian Eure <ian <at> retrospec.tv>, 72265 <at> debbugs.gnu.org
Subject: Re: [PATCH 0/1] Fix hardware acceleration support for librewolf
Date: Wed, 31 Jul 2024 11:08:04 +0600

Ian Eure <ian <at> retrospec.tv> writes:

> I’d like to have a better handle on *why* this isn’t working, and what
> alternate options may exist, before granting LW’s sandboxed processes
> full access to the store.

It doesn't work because RDD does not have access to drivers (in
/run/current-system/profile/lib/) and any shared libraries that driver
can use (anywhere in /gnu/store).  Which you could see when running LW
with MOZ_SANDBOX_LOGGING=1 environment variable or in my initial
message.  While we can add /run/current-system/profile/lib/ to whitelist
and partially fix this issue, I don't think we can predict what driver
would want to load.  So I don't really see any alternative solutions for
shared libraries problem.

> Since a lot of system config stuff ends up in there, and Guix doesn’t
> have a good way to manage secrets, it feels risky to me to open it up.

Is it really an issue?  Any program on your system already does that,
why LW any different?  It's a good enough solution for NixOS/FF not sure
why we have to do something different here.

> Do you have reproduction steps which demonstrate the issue?

It's in my initial message.  You just run LW with
MOZ_SANDBOX_LOGGING=1/MOZ_LOG="PlatformDecoderModule:5" and check your
GPU usage (intel_gpu_top for Intel GPU, not sure about others) while
playing video.

> I see it complaining about not loading libva, but setting
> `MOZ_LOG="PlatformDecoderModule:5"'[1] and enabling the various ffmpeg
> config bits, then playing a video, it *seems* like it’s using hwaccel.

I'm not aware of any other hwaccel implementation in LW/FF other than
VA-API.  If it's not loading libva it doesn't use hwaccel.

> The approach in LW is taken directly from the Firefox packages in 
> Nonguix -- can you reproduce your problem with that packages?

I can and it never worked for me.  I used to mantain my LW package
definition[1] where I put neccesary paths to LD_LIBRARY_PATH, but that
solution very specific to my setup and would not work as a general one.

-- 
Best Regards,
Nikita Domnitskii

[1] https://git.sr.ht/~krevedkokun/dotfiles/tree/master/item/src/guile/yggdrasil/packages/mozilla.scm

Message #17 received at 72265 <at> debbugs.gnu.org (full text, mbox):

From: Ian Eure <ian <at> retrospec.tv>
To: Nikita Domnitskii <nikita <at> domnitskii.me>
Cc: 72265 <at> debbugs.gnu.org
Subject: Re: [PATCH 0/1] Fix hardware acceleration support for librewolf
Date: Sat, 17 Aug 2024 15:20:02 -0700

Hi Nikita,

Nikita Domnitskii <nikita <at> domnitskii.me> writes:

> Ian Eure <ian <at> retrospec.tv> writes:
>
>> Since a lot of system config stuff ends up in there, and Guix 
>> doesn’t
>> have a good way to manage secrets, it feels risky to me to open 
>> it up.
>
> Is it really an issue?  Any program on your system already does 
> that,
> why LW any different?  It's a good enough solution for NixOS/FF 
> not sure
> why we have to do something different here.
>

I think it’s worth considering.  While any program can read the 
store, few of them run the huge volume of untrusted code that a 
web browser does.

That said, I’m okay with this approach.  Ideally, I’d like it to 
be a stopgap solution, but it’s a clear improvement on the current 
situation.  However, there are two changes I’d like to see:

1. Please remove the source patching from `make-librewolf-source' 
and move it into the librewolf package definition. 
`make-librewolf-source' is intended to produce a source tarball 
identical to upstream, and isn’t a good place to be adding 
Guix-specific patches.

2. Use the `substitute*' procedure instead of a patch file.  I 
maintain LibreWolf in my personal channel first, then contribute 
patches to Guix, and the patch file facility doesn’t work outside 
the main Guix repository.  I work this way because I’m not a Guix 
committer, and would like to run the latest version of LibreWolf. 
Guix is often several versions behind due to intractable delays in 
patch review.

With those two changes, your patch has my +1.  Though as noted, I 
cannot commit it, since I don’t have those privileges.


>> The approach in LW is taken directly from the Firefox packages 
>> in 
>> Nonguix -- can you reproduce your problem with that packages?
>
> I can and it never worked for me.  I used to mantain my LW 
> package
> definition[1] where I put neccesary paths to LD_LIBRARY_PATH, 
> but that
> solution very specific to my setup and would not work as a 
> general one.
>

Would you please file a bug report with them?  I’d be interested 
to hear what they have to say on the subject.

Thanks,

 — Ian

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.