Now Reading
Genode’s Browser Odyssey

Genode’s Browser Odyssey

2023-03-18 01:21:18

Norman Feske avatar

Genode’s Browser Odyssey

This text tells the twisted story behind Genode’s native net browser,
which is without doubt one of the most distinguished achievements of the challenge through the
previous yr. It’ll cowl our motivation behind this endeavor,
the rationale behind the selection of the browser engine, and plenty of technical

Earlier than beginning, let me give credit the place credit are due. Most of
the event described under was the work of my expensive colleague
Christian Prochaska, who relentlessly labored on the subject with a
super-human stage of endurance. My function was for probably the most half watching
in awe what he was doing.


I feel I am not exaggerating when stating that the
majority of utility areas for computer systems and smartphones is roofed
by HTML5-based net functions, that are universally accepted by finish
customers by now. By combining a contemporary net engine with Genode, we purpose at
making this vast number of modern-day functions available on
Genode. We’re significantly fascinated by utilizing these functions beneath
Genode on the PinePhone.

Nonetheless, that is something however a simple feat as a result of net engines usually are not solely
among the many most complicated software program stacks, but additionally transferring targets. We
however took the problem of re-targeting a whole HTML5 browser
engine to the Genode OS framework.
The breadth and depth of this line of labor has yielded invaluable insights
into the sensible challenges when combining a state-of-the-art browser
engine with microkernel-based working system expertise. With breadth, I
consult with the scope of challenges starting from taming extremely complicated construct
techniques, over the comprehension of your entire POSIX API floor and the
entire stack of protocol layers together with the C runtime,
networking, a number of utility frameworks, as much as web-application
interfaces. With depth, I consult with the necessity to look behind the curtains of
all these layers when troubleshooting points, e.g., like investigating
memory-corruption bugs in JIT-compiled Javascript code originating from a
distant web site.

Browser engines

The variety of web-browser expertise has dramatically
decreased through the previous decade.
In the case of trendy open-source HTML5 engines which might be suitable with the
majority of contemporary net functions, there exist solely three predominant
competing implementations, particularly WebKit developed by Apple, Gecko developed
by the Mozilla Basis, and Blink (Chromium) developed by Google.

Gecko engine
has a historical past reaching again to 1997 when it shaped the
foundation of the Netscape Navigator. Right now, it largely stays because the expertise
behind the Firefox net browser and the Thunderbird electronic mail consumer. Gecko is
an open-source challenge beneath the Mozilla Public License, which is a weak
copyleft license within the spirit of the Apache license.

Apple’s WebKit was initially
primarily based on the KHTML engine of the KDE project.
Within the years after the fork, it acquired extensively adopted past Apple’s merchandise.
For instance, Qt4’s HTML5 assist used to depend on WebKit. Additionally early
variations of Google’s Chrome browser employed this engine. WebKit is an
open-source challenge utilizing the weak copyleft LGPLv2 license and the liberal
2-clause BSD license.

Google’s Blink engine is the idea of the
Chromium project,
which in flip is the idea of the Chrome net browser. It originated as a fork
of WebKit to foster Google’s agenda to ascertain the browser as commodity
runtime for end-user functions. Therefore, Chromium launched performance
that was beforehand thought-about because the area of working techniques, e.g.,
sandboxing, hardware-accelerated graphics (WebGL), webcam assist, or audio.
Chromium is an open-source challenge utilizing principally the liberal 2-clause BSD

Right now, Chromium is by far probably the most extensively used browser engine. It has a market
share of
more than 60%.
Apple’s WebKit stays principally used
by Safari and iOS with a market share of round 20%. In distinction, the
market share of Mozilla’s Gecko engine had dropped under 10%.

The predominance of Chromium finally prompted Microsoft to exchange their
former in-house-developed Web Explorer with the Chromium-based Edge
browser for the Home windows working system. As one other former browser-engine
vendor, Opera adopted Blink as the idea of their present choices.

Given the dominant market share of Chromium, builders of net functions
more and more focus their growth and testing efforts on this single
implementation. In truth, net functions are anecdotally identified to work finest
on Chromium-based browsers.

This consolidation is a two-edged sword. On the one hand, provided that
Chromium is an open-source challenge, it offers customers and builders extra
freedom in comparison with the proprietary browser engines of the previous. On the opposite
hand, this expertise is in the end outlined and managed by a single
vendor, which drives its growth. Chromium is a mixture
of a fast-moving goal and intensely excessive complexity. Due to Google’s
funding, the thoughts share behind the expertise is successfully centralized
and follows the company pursuits of the corporate. The complexity of the
expertise – no matter its open supply license – makes a
community-governed fork virtually not possible.

For instance the latter level, Chromium consists of greater than 17 million traces of
supply code (sloccount, not counting feedback or white house), which is
near everything of the Linux kernel together with all drivers and CPU
architectures. In distinction to Linux, nevertheless, the course of Chromium is
managed by a single vendor. To place these numbers into perspective, in
phrases of supply code, the Chromium browser is round 50 instances bigger than
your entire Genode operating-system challenge (with all the greater than 250
parts mixed).

Although the near-monopoly place of Google within the browser
house is unlucky, there isn’t any practical various to Chromium for
pursuing our objective to host a big share of well-liked functions on
Genode, with low friction for the tip person. So we needed to settle for the
problem to convey Chromium to life on high of Genode.

Our place to begin was the Qt application framework.
Qt is a well-liked and wealthy cross-platform utility framework together with a
graphical widget software package and abstractions for the interplay between
utility software program and the underlying working system. Purposes
developed utilizing the framework might be focused in any respect platforms supported by
Qt, which embrace Linux, Home windows, and Mac OS X.

Since greater than 10 years, the Genode OS Framework helps the combination
of Qt-based functions into Genode-based techniques.
The Qt framework is supplied with bindings for a lot of well-liked open-source
libraries. Particularly, Qt model 4 supported bindings to the WebKit
browser engine, which in the end enabled us to convey the WebKit-based Arora
browser to
Genode in 2010.

The WebKit-based Arora browser operating on Genode model 10.05.

The characteristic set and dominance of Chromium prompted the Qt challenge to
substitute WebKit by the Chromium engine in Qt 5.4 in 2014.
The mixing of the Chromium engine in Qt5 is named QtWebEngine.
Nonetheless, for Genode’s Qt5 port, we used to
disregard QtWebEngine
as too complicated. Whereas WebKit comprised 1.8 million traces of code,
QtWebEngine is actually 10 instances bigger.

Nonetheless, now, with the objective of enabling the Chromium engine on Genode set,
QtWebEngine seemed like a beautiful and attainable path ahead, which
would in precept enable us to reuse our present integration of Qt with
Genode for the browser’s graphical person interface.

Constructing from supply for a known-to-work platform

To get acquainted with Chromium, we first took the overwhelmed monitor of constructing
QtWebEngine for one platform formally supported by the Qt challenge,
particularly Linux. For testing the end result, we used a minimal browser instance that
comes shipped with Qt.

The complexity of the Chromium code grew to become instantly obvious. Although
we disabled quite a lot of default options like geolocation, printing, PDF
assist, spell checking, WebRTC, or proprietary media codecs, our growth
machine outfitted with a 16-core AMD EPYC 7302P processor took nearly one hour to
construct QtWebEngine utilizing -j32. The ensuing libQt5WebEngineCore library has
a stripped dimension of 132 MiB (741 MiB with debug info), which is by far
the most important construct artifact we ever encountered.

FreeBSD and Linux/ARM64 as intermediate targets

Genode’s C runtime is predicated on FreeBSD’s libc, which is subtly completely different from
the glibc predominately used on Linux-based working techniques. To rule out
incompatibility points early on, we determined to first attempt constructing and utilizing
QtWebEngine on FreeBSD. Word that FreeBSD shouldn’t be formally supported. However
fortuitously, a
patch set
maintained by the FreeBSD neighborhood exists.
Utilizing the FreeBSD construct, we may progressively strip down the exterior
dependencies to solely fontconfig and the nss library, each of which we manually
disabled. The working construct end result on FreeBSD bolstered our confidence {that a}
Genode construct of QtWebEngine is in precept attainable.

A second supply of uncertainty was the unknown compatibility and efficiency of
QtWebEngine on the 64-bit ARM structure. To evaluate the chance, we constructed and
examined the minimal browser instance for Linux on the i.MX8 EVK board, which
labored effective.

Up till this level, all builds had been carried out on track. When concentrating on Genode,
nevertheless, now we have to cross compile. To rule out attainable cross-compiling
points and to seek out out the appropriate hooks for passing compiler flags, we constructed
the FreeBSD model of QtWebEngine on Linux and examined the end result on FreeBSD
on ARM64. Thankfully, we discovered that Qt’s qmake construct software has a stable assist
for cross-compiling by way of configuration information (mkspecs).

The experiment to cross-compile QtWebEngine for FreeBSD/ARM64 on Linux
required us to create a customized mkspecs definition, which gave us the insights
wanted later for concentrating on Genode, e.g., the hooks for specifying the identify of
the software chain. Additional elements wanted for the cross compilation had been the
FreeBSD headers and libraries, which we equipped by mirroring the corresponding
directories from FreeBSD. As soon as the construct succeeded, we had been capable of additional
scale back the hole in the direction of Genode by progressively eradicating all FreeBSD headers not current
on Genode. Every time the elimination of a header yielded a construct failure, we
patched the corresponding code and had been capable of instantly take a look at the end result on
FreeBSD, strolling on secure floor.

Concentrating on Genode

As much as not too long ago, the porting of software program to Genode was typically performed by
transplanting the construct guidelines for the Third-party software program into Genode’s construct
system. The complexity of Chromium, nevertheless, instantly guidelines out this
conventional porting method. So we picked up another thought we
investigated within the latest previous.

Finish of 2019, we began exploring the choice method of re-using
Third-party construct techniques to achieve Genode executables by way of a customized meta-build
software known as
Goa invokes Third-party construct techniques whereas supplying the
proper parameters for utilizing Genode’s software chain, compile flags, headers, and
linker scripts to be able to attain Genode-compatible executables. Initially, we
efficiently utilized the method to CMake primarily based construct techniques in addition to
Autoconf-based tasks.

Impressed by the promising outcomes of Goa, we began utilizing qmake in the identical
style, particularly by steering the construct utilizing a Genode-specific mkspecs
definition. As soon as we attained working construct outcomes for Qt’s base libraries
like QtCore and QtGui, we turned our consideration to QtWebEngine.

The qmake-based construct of QtWebEngine, in flip, invokes the Ninja construct system
utilized by the Chromium challenge. This cascaded use of construct techniques was not
with out bother. We needed to examine the interaction between qmake and ninja
to find out compile flags that had been unexpectedly not handed appropriately to ninja.
E.g., we needed to complement the definition of ninja’s extra_cflags and
extra_cxxflags from the corresponding QMAKE_CFLAGS and QMAKE_CXXFLAGS.

Chromium depends on nearly all sides of the usual C++ library, a few of
which weren’t coated by Genode (std::thread, std::mutex). We both
disabled the corresponding code parts or supplemented the lacking bits to
Genode’s customary C++ library.

The final word results of this work was an executable binary together with the
shared libraries for Qt5 and QtWebEngine that had been presumably suitable with

With the precept means of making executable binaries for the browser and its
libraries in place, the subsequent step was operating the binaries on high of Genode.
At this level, Genode’s cross-kernel ABI compatibility grew to become an indispensable
asset, which enabled us to check the preliminary operation of the browser on Linux
utilizing common debugging instruments just like the GNU debugger.

To call a couple of hurdles we needed to deal with:

  • Genode’s naming of shared libraries * differs
    from the standard lib*.so sample.

  • The dimensions of the QtWebEngine library exceeded Genode’s so-called linker space,
    which is a variety of the digital deal with house preserved for loading ELF
    binaries. This prompted us the rise Genode’s linker space from 256 MiB to
    400 MiB throughout all platforms.

  • Genode’s C runtime used to have a synthetic restrict of the utmost quantity
    of atexit handlers as a result of the usage of a static array. Chromium exceeded this
    restrict by a large margin, which prompted us to revise Genode’s atexit
    dealing with, finally eradicating the restrict.

  • Chromium makes use of shared reminiscence areas established through the use of mmap with the
    MAP_SHARED flag for exchanging information with a render thread, which is
    usually executed as a definite course of. Genode’s C runtime has no notion of
    MAP_SHARED. We tackled this downside by emulating MAP_SHARED by way of a
    devoted VFS plugin and by co-locating the render thread with the browser
    course of.

  • With these points addressed, the minimal browser began to indicate its first
    life indicators however behaved slightly erratically, crashing or displaying faulty
    graphical artifacts.
    Most crashes resulted from thread-safety problems with Genode’s model of
    getaddrinfo. The graphical artifacts resulted from the lacking MSG_PEEK
    assist in Genode’s model of recv.
    The mixture of the large complexity, the indeterministic nature of
    race situations, and reminiscence corruption made these points extraordinarily exhausting to seek out.
    As soon as noticed, the fixes had been comparatively straight-forward.

With the minimal browser instance working, we turned our consideration to constructing
and packaging the Falkon browser primarily based on QtWebEngine. Due to the
integration of QtWebEngine with Qt’s widget set, this preliminary model of
Genode’s Falkon port instantly appeared as a reasonably full net browser.

Early model of the port of the Falkon browser operating on Genode

At this level, we began the primary child steps for creating the 64-bit ARM
model of the minimal browser, which predictably triggered a unique set of
issues. Given our expertise with Java’s JIT compiler with ARM’s weak cache
coherency, we anticipated related issues with Chromium’s Javascript engine.
We discovered that Chromium invokes mprotect as a mechnism to invalidate the
instruction cache. So we mapped these calls to Genode’s cache upkeep
operations. With this downside solved, the minimal browser began efficiently
on 64-bit ARM, albeit operating very slowly. The following step of compiling
the Falkon browser for 64-bit ARM too, succeeded with no additional showstoppers.

With the preliminary model of the browser working, we began testing through the use of it
immediately on Genode’s
Sculpt OS and
thereby found a number of nook circumstances and noticed the extreme want for

For instance, we discovered that the browser incessantly obtains random
numbers by accessing /dev/urandom, which we backed by the
jitterentropy-based random quantity generator. These random numbers are
computationally pretty costly. We may relieve the difficulty by combining
jitterentropy with an affordable pseudo RNG (jitter_sponge).

Moreover, we optimized the choose mechanism of Genode’s C runtime as effectively
because the entry of pthreads to sockets. A number of associated libc inner
mechanisms acquired optimizations, particularly the entry to thread-local
storage and process-local inter-pthread synchronization.

One break-through realization was the dimensioning of the reminiscence restrict of the
Javascript engine, which occurs to be decided by getrlimit. Genode’s
model of this perform didn’t return a significant worth for RLIMIT_DATA,
which resulted in a overly tight restrict, severely impeding the efficiency and

Performance-wise, we needed to allow libnss for Genode, which is utilized by
Chromium for the validation of SSL certificates.

Most video-streaming websites ship mp4 streams, which our model of Falkon
didn’t assist. To typically assist media playback, we needed to allow
QtWebEngine’s proprietary codecs.

Even with the proprietary codes enabled, we confronted a protracted standing situation with
accessing YouTube on ARM. The Javascript engine would crash not lengthy after
YouTube introduced its cookie-confirmation dialog. Our investigation led us into
the internal guts of the Javascript’s JIT compiler, which produced binary code
with inter-thread synchronization points. We in the end discovered that the
problematic code is definitely by no means used within the Linux model of Falkon. It
seems that the distinction was attributable to the optimization
webengine-v8-snapshot. Early on throughout our porting effort, we intentionally
disabled this optimization to ease our life. With the optimization enabled,
incessantly used Javascript code is pre-compiled on the compilation time of the
browser. The pre-compiled code works appropriately. With the optimization
disabled, the issue happens on Linux as effectively. Therefore we may side-step the
downside by enabling the optimization.

With this street block eliminated, we may lastly have a good time taking part in YouTube
movies on Genode.

The Falkon net browser taking part in a YouTube video on Sculpt OS

With our aspiration to make use of Falkon on Genode for video-chat eventualities, we
investigated the means to combine the browser’s media amenities with
Genode’s corresponding interfaces. We had three areas of curiosity, audio
playback, audio capturing, and video capturing.
Our objective is to maintain our port of the browser as little invasive as attainable to
ease future updates of the QtWebEngine. Therefore, as a substitute of enhancing the browser
with Genode assist, we as a substitute want to emulate present and time-tested
interfaces already supported by the browser.

For audio, Genode already options an emulation of the OSS (open sound system)
API within the type of a so-called VFS plugin. It transparently interprets an
utility’s interplay with a /dev/dsp pseudo gadget to Genode’s native
audio interfaces. The browser employs a library known as sndio that encompasses a
variety of audio backends, with OSS being one possibility. Therefore, sndio conveniently
bridges the hole between Genode’s OSS emulation and the browser’s audio

In the identical spirit, we investigated attainable choices for video capturing and
discovered three potential hooks, particularly Video4Linux, faux (auto-generated take a look at
animation), or supplying a video file containing YUV pixel information as command-line
argument. None of these choices met our want for a easy answer that
might be simply built-in with Genode’s present seize session interface.
Nonetheless, because of the number of video-capturing again ends that we may take
as blue prints, it was comparatively easy to complement our personal implementation.

The picture above illustrates the interaction of the browser with the
pseudo units offered by plugins for Genode’s digital file system.
Due to this structure, the Genode world stays cleanly separated from
the POSIX world on high.

With respect to video capturing on Genode, the seize service is offered by
a intelligent mixture of parts depicted under.
A second occasion of the nitpicker GUI server is used as a video bridge between
the USB webcam driver and the browser. Each events connect with this nitpicker
occasion, which naturally controls the info path of the video stream. Therefore,
the capturing of the digital camera is totally decoupled from the browser.

Knowledge path between the webcam and the net browser

In truth, the USB webcam subsystem that we added within the
21.10 release of
Sculpt OS, a disposable webcam driver is began and eliminated on
demand relying on the presence of a seize consumer. This structure
in the end clears the way in which to implement a digital camera kill change that’s out of
attain of the (untrusted) browser, placing the person into the place of
final management over the digital camera.

Concerning the capturing of audio information, we sadly discovered the sndio backend
of the QtWebEngine underdeveloped. Even after updating the backend to a extra
latest model that presumably options audio capturing by way of sndio, we had been
unable to achieve workable outcomes.

We in the end determined to sidestep sndio by a customized written OSS backend that
is particularly geared to the characteristic set offered by Genode’s OSS emulation,
largely avoiding complexity. With the customized OSS backend in place, we reached
the precept performance wanted for video chat. Although additional
optimization steps are wanted for real-world use past technical
demonstrations, the trail in the direction of utilizing WebRTC-based video chat on Genode is

See Also

The Chromium-based Falkon net browser operating on the 64-bit ARM MNT-Reform open-hardware laptop computer

Internet-applications survey

As said within the introduction, we pursued this difficult line of labor in
the hope to convey the wealth of contemporary net functions on Genode. We’re
joyful that this declare got here to fruition. In truth, we had been in a position to make use of loads of
net functions in Genode’s model of the Falkon net browser on Sculpt OS
operating on our common laptops.

Since having built-in the net browser into the Genode-based Sculpt OS, utilizing
the browser has turn into every day routine for us Genode builders, which I might
name a powerful success.

State of the media options

We’re at the moment within the means of maturing the browser’s media capabilities
by connecting the browser’s media again ends to corresponding Genode companies,
most notably an audio driver (on x86 PC {hardware}) and a USB webcam driver on
each ARM and PC {hardware}.
Though we’re joyful to see the media options working in precept,
we aren’t there but, evidenced by audible distortions and latencies.
Given the heavy work load and complexity of the browser,
this isn’t stunning. To observe our ambition to host WebRTC-based video-chat
eventualities on the resource-constrained PinePhone, nevertheless, we have to
deeply perceive and optimize these non-functional elements.
That is our motivation behind emphasizing quality-of-service subjects on Genode’s
not too long ago revealed
road map for 2022.

Interactive efficiency

We examined the browser on PC {hardware} in addition to
on 64-bit ARM {hardware} – particularly NXP’s i.MX8 SoC – on Sculpt OS.

On PC {hardware}, the browser’s interactive efficiency is completely usable.
Even heavy-weight web sites like might be visited and scrolled with out
lagging. The person expertise on ARM, nevertheless, shouldn’t be passable but.
The browser visibly overstresses the system. Although it’s useful,
the response to person enter has a perceivable latency and scrolling stutters.

From cross-correlating Genode’s model of Falkon with the identical browser
operating on Linux, we realized that the efficiency of the ARM platform shouldn’t be
easy in each circumstances. Genode’s model of the browser shouldn’t be far off the
efficiency noticed on Linux. Nonetheless, we additionally noticed that the Chromium
browser (not Falkon) is ready to attain a easy efficiency on the identical ARM
platform. These assessments trace at a promising potential for additional optimization.
Particularly, the comparability of Falkon vs. Chromium on Linux hints at
attainable friction because of the integration of Chromium with Qt. It’s tempting
to research the interaction of Qt and Chromium – particularly the response to
user-input occasions – intimately.

On each PC and ARM {hardware}, we noticed the networking throughput as a
bottleneck, particularly on web sites that set off a lot of TCP
connections. Therefore, Genode’s TCP/IP protocol stack and its interaction with the
C runtime appears to be like like a rewarding optimization vector.

Moreover, we noticed a noticeable impact of file-system used for the
browser cache. Utilizing an in-memory file system yields a visibly improved
interactive efficiency over the usage of a persistent file system, which we
discovered stunning. Profiling the file-system entry patterns of the browser
would possibly reveal additional optimization alternatives.

Lastly, the usage of a number of CPU cores has important results. The browser is
a closely multi-threaded utility. Even with a reasonably complicated web site
like, the browser spawns over 40 threads. When spanning this workload
over all 4 CPUs of the ARM platform, the inter-CPU cross-talk of the
threads impedes the efficiency. Alternatively, the efficiency of solely a
single CPU doesn’t suffice for an fulfilling person expertise. We discovered the use
of two CPUs – each distinct from the boot CPU – to be the candy spot. Nonetheless,
the numerous affect of the CPU useful resource partitioning hints at an
untapped potential for optimization, both by pinning tightly coupled threads
to particular person CPUs based on prior information or by balancing CPU hundreds

Many tempting subjects to work on…


The scope of net functions that instantly labored with out flaws on
Genode’s model of the Falkon net browser is positively stunning.
Nonetheless, whereas test-driving WebRTC shoppers – particularly Jitsi – we
already skilled the browser as a steadily transferring goal. Relying on
the mixture of browser variations and Jitsi variations, establishing
a bi-directional video chat was a hit-and-miss expertise. The most effective outcomes
might be obtained by internet hosting a managed occasion of Jitsi with a
known-to-work model whereas the official model hosted at behaved slightly erratically. E.g., the press of the
button to affix a chat wouldn’t be recognised with the model of Chromium we
are utilizing. That is notably not a problem of our port of the Falkon browser however
might be reproduced on the upstream model of the browser on commodity Linux
techniques as effectively. Related erratic conduct might be noticed when utilizing Firefox
on Linux.

From these observations, we take that the implementation of the net requirements
that underpin present WebRTC-based options are something however secure. In
opposite, the options appear to be tied to most up-to-date browser variations.
Browsers have to be repeatedly up to date to be able to uphold performance, which
brings us again to the tight dependency on a single vendor as mentioned in
the introduction.


There are two attainable avenues to counter the moving-target nature of
browser-based WebRTC options. First, by internet hosting a known-to-work model of
the server software program inside a (digital) non-public community, i.e., secured by way of
Wireguard. Second, by maintaining Genode’s model of the browser with the
upstream model of Chromium. It goes with out saying that the latter
requires steady effort.

Our future might be a mixture of each approaches. Due to the way in which of how we
interfaced the browser with Genode – largely with out code modifications of the
browser – we count on browser updates to remain economically viable when pursued
at bi-annual intervals. Sadly, the character of the browser as a transferring
goal comes with the chance of regressions, which can’t be dominated out and will
require unplanned debugging and testing efforts. We’ve to simply accept this

For the dependable collaboration of a closed group, a hard and fast
and known-to-work mixture of a browser model and server model,
protected by a VPN, is a beautiful various as a result of regressions can’t
happen. When using Genode’s robust sandboxing capabilities mixed with a
safe VPN answer, the usage of a barely outdated browser model as a WebRTC
equipment strongly sandboxed by Genode, doesn’t pose a danger. We don’t belief
the browser anyway, in any case. We plan to pursue this course by combining
the Wireguard VPN answer with Genode.

Have I discussed that Wireguard is featured on our street map for this yr?

Source Link

What's Your Reaction?
In Love
Not Sure
View Comments (0)

Leave a Reply

Your email address will not be published.

2022 Blinking Robots.
WordPress by Doejo

Scroll To Top