Re: Guix driver paths for icecat RDD sandbox

[John Kehayias]

Hi Jelle and guix,

On Sun, Jan 15, 2023 at 04:37 PM, Jelle Licht wrote:

> Hi guix,
>
> I was playing around tyring to get hardware enabled video decoding
> working in icecat and/or firefox in guix, and found out that the fine
> folks working on Nix have already gotten a patch upstreamed that allows
> stuff in /nix/store to be loaded[0]. (Grep around for '/nix/store' in
> our icecat sources to see what I mean).

I think hardware accelerated decoding is more than just nice to have due to the 
massive
savings in CPU usage (and thus battery power for a laptop beyond general 
overhead). So
props for working on this!

As a disclaimer, last I tried icecat was not giving me hardware video decoding, 
but I did
fix it in firefox, at least in my testing. As that is not in Guix (for branding 
and/or
addon interface, is that correct?) I won't reference that in any detail, though 
I know you
(Jelle) are familiar with the details there. I'll explain a little below, for 
others
though. Hardware acceleration does let me watch the highest quality videos I 
could find
with minimal CPU usage.

>
> From what I can see, the RDD whitelist reads through symlinks, so the
> actual target file needs to be whitelisted before the file is loaded in
> the sandbox.
>

Yes, that is my understanding as well. And we should note that the RDD (Remote 
Data
Decoder) sandbox is a newer-ish feature that I'm at least aware of in the 
context of video
accelerated video decoding. This is different from other sandboxes used in 
icecat/firefox.

However, there is also an automatic allowance for anything in LD_LIBRARY_PATH. 
That was
the fix I used, drawing upon Mark Weaver's work in icecat to get everything in 
the runpath
for some drivers (e.g. from mesa). Adding that to LD_LIBRARY_PATH allows the 
RDD sandbox
access to them. And, as always, getting good debugging of library loading in 
sandboxes is
a bit tricky. I can probably dig up what I found and used if that is of use for 
anyone
(there's some Mozilla flags at least).

> Without this (or a similar fix), we'd need a custom package per possible
> value of LIBVA_DRIVERS_PATH, as loadable libraries for hardware
> accelaration do not seem directly configurable via
> 'browser/app/profile/icecat.js' at runtime. I may be wrong here, but
> this seems to also imply that a recompilation of icecat would be
> required as well every time one of these 'inputs' change :/.
>

Agreed, that is a potential downside, but what are the possible libva drivers 
in Guix?
There's mesa and possibly libvdpau-va-gl? Mesa is already needed anyway (and 
rarely
changes, though see discussion about more staging/feature branches). I also 
didn't see a
way to do this at runtime, based on how the RDD sandbox works.

There's also the question on foreign distros, which I don't know about.

> OTOH, it would have some drawbacks:
> - It hardcodes /gnu/store, instead of $MY_MAGIC_STORE_LOCATION
> - It allows loading of pretty much anything in the store by the
> sandboxed process.
>
> The second drawback seems pretty iffy, but the current suggested
> workaround is to disable the sandbox entirely.
>

I also share some concerns on the second solution but I'm not expert. On the 
one hand, we
expect the store to be world readable in general. On the other, sandboxes are 
there for a
reason and increasing a possible attack vector (say, on old version of 
something in the
store or similarly known exploit) is to be avoided. So I don't know.

> So that leaves us with 2 questions:
>
> 1. Do we want apply a patch to whitelist '/gnu/store'?
> 2. If so, would we want to also send this patch upstream firefox? They
> seem open to accepting it.
>

With my caveat that I didn't get this working on my end for icecat (I should 
retry), I
would be more for a limited workaround. But that might not be workable in 
general. I don't
use icecat much, and rarely for videos, so I haven't pursued it further. This 
might be a
good time to try again though.

If we go the second route I think it makes sense to upstream it in light of the 
similar
patch from Nix.

> I've opened an upstream issue for a similar treatment of /gnu/store,
> which may also simplify the 'build-sandbox-whitelist' phase of our
> icecat package[1] if accepted. I'm not entirely sure if that is
> ultimately a good thing yet though.
>
> Happy to hear any thoughts on this subject.
>
> - Jelle
>
> [0]: <https://bugzilla.mozilla.org/show_bug.cgi?id=1761692>
> [1]: <https://bugzilla.mozilla.org/show_bug.cgi?id=1808408>

All for better hardware video support, alas the ever-growing land of sandboxes 
and
containers (somehow I keep getting drawn in!).

John