So I installed the great brunch framework on my laptop after a hiatus of a couple of months. I still dislike the fact that the Linux containers are running under a VM on Chrome OS. Sure it is more secure as the containers won’t be able to access the host hardware directly etc. It is also slightly inefficient. So I tried both chromebrew and brioche. Note that brioche only supports brunch (thus half of this post won’t apply to official Chrome OS builds).
Chromebrew is like brew.sh (Homebrew for Mac) but for Chrome OS. It works for any developer mode-enabled Chrome OS environment. In other words, it is a package manager, like apt/dnf/zypper. There is no virtualisation here at all, the software distributed via Chromebrew runs directly in Chrome OS. Theoretically, this is the fastest given zero penalties from virtualisation. It’s also plagued by the restrictions of Chrome OS and its non-standard setup.
Brioche, on the other hand, relies on the brunch toolchains and sets up containers via LXC. Those containers are running directly in Chrome OS (as opposed to under the termina VM like in the official method from Chrome OS). Supposedly this option gives the balance between compatibility and efficiency, at the cost of security (the containers have full access to the host hardware).
My personal experiment is a bit of a mixed bag, especially when it comes to Linux GUI application launchers. Most users should simply go with the officially supported way to run Linux applications.
Now, if you’re geeky or feel nerdy today, let’s dig a bit deeper into how Chrome OS manages the application launchers for Linux applications.
In Chrome OS, there is a bridge service (or guest tool) called garcon (given the prevalence of French words in the repository, I bet this should be pronounced as the French origin garçon). According to the documentation from the link, garcon binary is shipped as part of Chrome OS (more specifically, part of the VM termina). It is bind-mounted to be available from the running containers, and then it uses gRPC to have bi-directional communication with the Chrome OS host. This is the service that is responsible for creating and maintaining the Linux application launchers in Chrome OS (and a lot of other nifty features). Essentially, garcon runs as a daemon and makes sure the .desktop files in the containers will have the relevant launchers in Chrome OS.
That’s how it works in the official method. What about chromebrew and brioche? Chromebrew runs directly in the host environment, so they come up with an idea to create PWAs that would then launch the Linux applications via RESTful HTTP calls to a service called crew-launcher. To streamline the installation process, crew-launcher uses D-Bus to open a new Chrome tab (the Chrome from Chrome OS) for the wrapper PWA so that it can be installed as a Chrome OS launcher.
Brioche? At the moment, there isn’t such a solution. I thought to myself, how hard can it be? Now I dug a hole for myself, I’m aiming to have something working, hopefully before the new year. I experimented with both approaches, using gRPC like garcon, and creating wrapper PWAs with a Web server. The former failed as soon as I found out that I can’t connect to the gRPC port opened by vm_concierge. In fact, there is no more port (garcon used to listen on 8889), Chrome OS has its own forked gRPC that supports VSOCK. They’re using VSOCK to communicate between the VM host and the guest. Heck, they even mentioned in this issue my idea which was to exploit the very security risk.
The second solution (akin to crew-launcher) worked in my proof of concept. Similar but it’ll have to be a slightly different approach because we can’t send D-Bus to the Chrome OS host to open any new tabs. My line of thoughts is to then make a Web App that communicates with the server running in the container to discover installed Linux applications, and then the user will have to manually click and install them as the PWA wrapper in Chrome OS launcher. I’ll make a new post when I have something usable and worth sharing :)
Leave a Reply