From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id YM1PBZKnxGM0VgEAbAwnHQ (envelope-from ) for ; Mon, 16 Jan 2023 02:25:38 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id 0JZiBJKnxGOihAEAG6o9tA (envelope-from ) for ; Mon, 16 Jan 2023 02:25:38 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 89677376BB for ; Mon, 16 Jan 2023 02:25:37 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHEFS-0002ro-2U; Sun, 15 Jan 2023 20:25:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHEFP-0002rC-OW for guix-devel@gnu.org; Sun, 15 Jan 2023 20:25:15 -0500 Received: from mail-40131.protonmail.ch ([185.70.40.131]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHEFM-0003Ln-3p for guix-devel@gnu.org; Sun, 15 Jan 2023 20:25:15 -0500 Date: Mon, 16 Jan 2023 01:24:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1673832298; x=1674091498; bh=3anBbkf5/qjjT3tw4lCXNK1ZGqo58XmnazaaNF7ggqc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=bbZ5fKwU8Cda17/W8o19/8spVIuQwGhXheEDziwL1jyk0MviV/FRkZpg99wvt7K6j nnDXmRRDvTJfmW8FHDe2xjPflpg6uqqTDbCheguLbEy9BfpVu4Bh84rborlZjn+z4L bnlPUguSvDmx3CljlD9s00fxzlS+A2OKrQeWRu98Cq9JFzkxVhJBbp+X3yQJn1IaQA 3lo8+vZriADkYtdt8mQDbXv5mE5JiOxrlcVUMU26EBSTPAkIbt1YoHz2HiMfiHv89d zOZ6Wr9RzH8xkyZNqzarAMih3SjtmIIGvSL6hVEkW8w5Mv3jkS/dc3/cG5YY+zyYrb /+Yj8SbUQ4WKQ== To: Jelle Licht From: John Kehayias Cc: guix-devel@gnu.org Subject: Re: Guix driver paths for icecat RDD sandbox Message-ID: <87v8l78e5g.fsf@protonmail.com> In-Reply-To: <87o7qzzu49.fsf@fsfe.org> References: <87o7qzzu49.fsf@fsfe.org> Feedback-ID: 7805494:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.131; envelope-from=john.kehayias@protonmail.com; helo=mail-40131.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: guix-devel-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=bbZ5fKwU; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=quarantine) header.from=protonmail.com ARC-Seal: i=1; s=key1; d=yhetil.org; t=1673832337; a=rsa-sha256; cv=none; b=EnzX3a9J5FsgfSIfw0hR0RvnlZnJJBl4FSu2pCpUXRZD10+cj+TCF86YIalgNd8avbihqS awU0RZbsmsaIzq7o3tpLjo70By9mS/PsM/0f62Z2HTbWbZXLk1LOyw8fmuNKxz15PJnDrf zgy3EkFTtTdQPLXz678sYmAMyH8hu2tgIuAhNinUTs+riRLSJAuCsctaC61tP5ypx6v7Id 1zmO9aCIRYD7cGeswCi6AMSFpGnZkxn4KdFiRyKzXXsA3cTSy5XtyBuk058eVmJ8HJ61aY xgM3GlQ8OMwee9u0zoHGrpvoU1ESMKK5VPwRuIFQ9NZ3A1EDg4Fm3MXbTCHi9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1673832337; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=3anBbkf5/qjjT3tw4lCXNK1ZGqo58XmnazaaNF7ggqc=; b=azC8Et+0fjQUfd+9rGKcCbcKdL56uzGQW+UJuTO304K4nATO/v05mssUAMhG8/GzGtAkNO +UF6lQjN7LMid8sF7UI+b8Yc0WaTHjU4XEH3Rt5KaSSTilUlh4YAWD7disS9e58ujiUAlv i2RcLbADftVvrOfOtcqz3JSOMUmYicAJQ27aXNKfQk9AX/8jkegzaotvA5wREAmjXMbAZY tXx6H6Pd+k8GIj2zmK+sZKifwN4SVd0AcDu1+CRNFSOMSj9tv6aYKAziWXqE1ebAtZEc6N Bv35o5vhiXNwhB5Owvzu9VNrLzovS764lWqB/32N9X5JziK+lNapeTivnEpkOg== X-Migadu-Queue-Id: 89677376BB X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=bbZ5fKwU; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org"; dmarc=pass (policy=quarantine) header.from=protonmail.com X-Migadu-Spam-Score: -7.81 X-Spam-Score: -7.81 X-TUID: 4nkYoNCzlX+L 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 ov= erhead). So props for working on this! As a disclaimer, last I tried icecat was not giving me hardware video decod= ing, but I did fix it in firefox, at least in my testing. As that is not in Guix (for bran= ding and/or addon interface, is that correct?) I won't reference that in any detail, th= ough I know you (Jelle) are familiar with the details there. I'll explain a little below, f= or 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 (Rem= ote Data Decoder) sandbox is a newer-ish feature that I'm at least aware of in the c= ontext 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_PA= TH. 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 th= e RDD sandbox access to them. And, as always, getting good debugging of library loading i= n 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 drive= rs in Guix? There's mesa and possibly libvdpau-va-gl? Mesa is already needed anyway (an= d 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 th= e one hand, we expect the store to be world readable in general. On the other, sandboxes a= re there for a reason and increasing a possible attack vector (say, on old version of some= thing 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 shoul= d retry), I would be more for a limited workaround. But that might not be workable in g= eneral. I don't use icecat much, and rarely for videos, so I haven't pursued it further. Th= is 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]: > [1]: All for better hardware video support, alas the ever-growing land of sandbo= xes and containers (somehow I keep getting drawn in!). John