Guix driver paths for icecat RDD sandbox

Guix driver paths for icecat RDD sandbox

[Jelle Licht]

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).

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.

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 :/.

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.

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.

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

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