[PATCH 0/1] Fix hardware acceleration support for librewolf

  • Open
  • quality assurance status badge
Details
2 participants
  • Ian Eure
  • Nikita Domnitskii
Owner
unassigned
Submitted by
Nikita Domnitskii
Severity
normal
N
N
Nikita Domnitskii wrote on 24 Jul 07:44 +0200
(address . guix-patches@gnu.org)
cover.1721797552.git.nikita@domnitskii.me
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:

Toggle snippet (9 lines)
$ 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

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

Toggle snippet (10 lines)
$ 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

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
N
N
Nikita Domnitskii wrote on 24 Jul 07:44 +0200
[PATCH 1/1] gnu: librewolf: Add guix drivers paths to RDD whitelist
(address . guix-patches@gnu.org)
d58e28b577d0c7f9ba30314b409dc5d4749b69ec.1721797552.git.nikita@domnitskii.me
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

Toggle diff (65 lines)
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
I
I
Ian Eure wrote on 31 Jul 02:12 +0200
Re: [PATCH 0/1] Fix hardware acceleration support for librewolf
87cymutnnr.fsf@meson
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

N
N
Nikita Domnitskii wrote on 31 Jul 07:08 +0200
87ed7a5etn.fsf@domnitskii.me
Ian Eure <ian@retrospec.tv> writes:

Toggle quote (4 lines)
> 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.

Toggle quote (3 lines)
> 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.

Toggle quote (2 lines)
> 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.

Toggle quote (4 lines)
> 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.

Toggle quote (3 lines)
> 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

I
I
Ian Eure wrote on 18 Aug 00:20 +0200
(name . Nikita Domnitskii)(address . nikita@domnitskii.me)(address . 72265@debbugs.gnu.org)
874j7i6aqm.fsf@meson
Hi Nikita,

Nikita Domnitskii <nikita@domnitskii.me> writes:

Toggle quote (14 lines)
> Ian Eure <ian@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.


Toggle quote (12 lines)
>> 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
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 72265@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 72265
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch