FireFoxOS and its use of Linux






Aimee Maree Forsstrom
mozillians.org/en-US/u/aimeemaree
aimeemaree.info
@aimee_maree

Little introduction to me

My name is Aimee Maree ForsstromBeen using Linux since Debian PotatoContributed to various OSS Web projectsMentor Children and have taught Python, Scratch, Alice, PHP, HTML/CSS, JavaScript and iOSContributed to Meego and learnt QT which lead me onto FireFoxOS

Recently was working with Mozilla in the Mobile Support Team

I have built mobile applications for FireFoxOS, iOS, Android and Windows Phone

Alot of my day to day work is within the mobile web architecture space and my main hobbie and passion is embedded Linux

What is FireFoxOS

Mobile Operating System developed by Mozilla to power mobile devices

Utilises Linux, Android and Gecko (FireFox browser engine)

By now you would of heard about FireFoxOS from MozilaIt has been in the wild now for just over a yearFirst started life as the B2G project aka Boot 2 GeckoIt is still reffered to as B2G in github repos and documentation on the webIt is Mozillas attempt at entering the mobile platform spaceIt is aimed at lower end smart phones but this is not a limiting factor it just means that a main ideal is to allow it to run with a small memory footprintIt is built using Open Web Standards and as such you can deploy and maintain your own apps without the need for distribution through the Mozilla MarketPlace

FireFoxOS Architecture Layers

The main layers are what I like to call the Three Gs

And under those layers is the device itself

These layers represent the full FireFoxOS Architecture stack

When you write an application for FireFoxOS you do so using web technologies HTML5, CSS and Javascript

the application sits at Gaia level and accesses lower levels through Gecko so just like iOS and WindowsPhone the applications are contained (sandboxed) within the top level where app developers place calls to lower levels through middleware

From a security perspective each application runs it its own sandboxed environment

Gaia

User interface application for Firefox OS devicesWeb application running atop Firefox OSComes with some standard applicationsIsolated from Gonk communicates through Gecko

So at the top we have Gaia which is the web application running atop of Gecko

Comes with a standard stack of applications, phone caller, messaging app, contacts, calendar etc

When you roll your own firefoxos Gaia will include the basic stack of common applications (phone dialler, calendar, messaging, marketplace and some others) and then you can apply various other applications at that level for your device

Gaia communicates to Gonk through Gecko

Gecko

Application run timeCollection of API's for hardware accessRenders Web ContentACLs and permissions are controlled in Gecko

Gecko holds the Web APIs that are used for communication between the upper level of Gaia and the lower level of Gonk

Gecko is the "application runtime" of Firefox OS and Implements the open standards for HTML, CSS, and JS

Gecko is the middleware code which is composed by (among others) a networking stack graphics stack (which delegates operations to the GPU when needed) layout engine (for rendering HTML content) virtual machine (for running Javascript code) porting layers for various different platforms which live inside the B2G folder of the source code

Gonk

Linux KernelDevice DriversHardware Abstraction Layer

Isolated from GaiaCommunicates through Gecko/B2G

Magic Black Box

Gonk is the name given to the layer that holds the Linux Kernel, Device Drivers and the Firmware needed to communicate directly within the device

It is a lower level operating system of the Firefox OS platform, consisting of a Linux kernel (based on the Android Open Source Project (AOSP)) and userspace hardware abstraction layer (HAL).

It is isolated from the higher levels and communicates in the userspace through the gecko layer and Web APIs

Its the core component that is adapted for differing chipsets and device hardware features, and one could say it is largely chipset-specific which we will speak more about later.

Lets dive deeper into Gonk

Looking into some of the components of the Gonk layer we can see;The Radio Interface Layer (RIL) which interacts with the modem hardware in the phone. It consists of two components: rild daemon talks to the modem firmware rilProxy proxies messages between rild and the b2g process

There is a mediaserver which controls audio and video playback. Gecko communicates with the media server through an Android RPC mechanism. Also netd process akak the Network daemon that interacts directly with hardware network interfaces

Bluetooth and other service-level daemons providing access to hardware capabilities. These are common modules obviously there are others that can and will sit at this level

Linux Kernel distro uses libraries from Android (GPS, camera, etc.) and other open source projects Linux, libusb, bluez, to name a few.

Then we have the Firmware and drivers at the lowest level

How Gonk handles a request

So as we have discussed Gaia speaks to Gecko A single request from Gecko can trigger a complex series of operations, initiated and managed by Gonk, in the device.

In this example, the Radio Interface Layer (RIL) in Gonk is responsible for controlling the modem hardware that will dial the requested number. The b2g process communicates the dial request to the rilProxy, which forwards the request onto the rild service-level daemon. The rild controls the actual modem hardware via the Linux kernel and any associated modem firmware and drivers. The rild sets up the modem and causes it to dial the number. Any changes in the modem state (dialing, ringing, busy, connecting, connected, disconnecting, disconnected, or incoming) are reported via the b2g process up the Firefox OS stack.

How the layers communicate

As mentioned Gaia is where the application will liveThe app communicates to Gecko through the execution environment who in turn talks to the permissions manager who is the only access the Web APIS to the underlying hardware.

who checks through ACLs what can/can not be done [ Matrix of roles and permissions required to access Web API functionality.] Credential Validation: Authentication of apps/users.Permissions Store: Set of privileges required to access Web API functionality.

Once confirmed it then communicates through Web APIs who talk to boot to GeckoIt is then at this point that communication with Gonk is initiated Gonk will then communicate directly to the hardware device

HAL

http://mxr.mozilla.org/mozilla-central/source/hal/ Not exposed directly to JavaScript codeC++ API accessible to higher levels of GeckoGecko communicates with Gonk directly through the HALThis communication is run in a sandbox environment

Now that we have had an overview of Gonk lets explain some other components

Within Gonk sits the hardware abstraction layer which is one of the porting layers of Gecko. It handles low-level access to system interfaces across multiple platforms using a C++ API that's accessible to the higher levels of Gecko.

The API is implementation of the HAL is generally modified depending on the needs of the device

This hardware abstraction layer is not exposed directly to JavaScript code in Gecko for security reasons

The sandbox implementation simply proxies requests made by content processes and forwards them to the "Gecko server" process. The proxy requests are sent using IPDL which will discuss later

init process

Will execute processes defined in init.rc and the successor init.b2g.rcLaunches userspace init processOnce the init process is launched, Linux kernel handles system calls from userspace, and interrupts from hardware deviceHardware features are exposed to userspace through sysfs

The Firefox OS init.rc is basically stock Android with patches to include things required to kick-start Firefox OS, therefore can vary from device to device depending on the needs.

The init process in Gonk also handles mounting required file systems and spawns system services.

After init is ran, a userspace init process is launched. Once the init process is launched, the Linux kernel handles system calls from userspace, and interrupts from the hardware.

After that, it stays around to serve as a process manage which is similar to other UNIX-like operating systems.

BootStrap

Execution begins in the primary bootloader

From there, a succession of increasingly higher-level bootloaders bootstrap the next loader in the chain.

the general system bootup flow goes from bootloaders in the Kernel space, to init in the native code, to B2G and then Gecko in the user space, and then finally to the system app, window manager, then the homescreen app inside Gecko.

This is what all other apps are then executed on top of.

Inter-Process Communication

Inter-process Communication Protocol Definition LanguageDeveloped by MozillaC++ code to pass messages between processes or threads in a secure wayApps communicate with service-level daemons via IPC

Inter process communication is handled by IPDL which was developed by Mozilla and is used across various projects not just FirefoxOS

All IPDL messages are sent between parent and child end points, called actors. An IPDL protocol declares how actors communicate: it declares the possible messages that are sent between actors, and a state machine describing when messages are allowed to be sent.

IPC Architecture

In FirefoxOS we have a Multi-process Architecture This means each app is ran in a different process allowing it to run with the least amount of privileges.

As you can see there is a single parent process called b2g. The b2g process has a child process called nuwa, you can think of nuwa as the main child process which is then forked everytime an app is started

As mentioned the default is that child processes are run with the minimal set of privileges.

When higher privileges are needed they need to go through the parent process (b2g). This is where Inter-process Communication (IPC) comes into place. Each child has an IPC channel, to the parent which will be used for its communication.

IPC Parent Child relationship

So if your familiar with using Unix sockets then this system will not seem unfamilar, FireFoxOS uses Unix sockets created with the socketpair system call, to send messages across the process boundary.

The system calls sendmsg and recvmsg Each process has its own dedicated thread that handles the socket operations, this is called an IOLoop. Each IOLoop thread has its own outgoing message queue, which is used by the main thread to send a new message across the channel.

All IPDL messages are sent between parent and a child end points, aka actors. An IPDL protocol declares how actors communicate: it declares the possible messages that may be sent and a state machine describing when messages are allowed to be sent.

Hardware Access

Apps access hardware only via Web APIsGecko is the sole gateway to mobile device No native API no other back doorsApps are ran in a sandboxed mode

Web apps have only one entry point to access mobile phone functionality which are the Firefox OS Web APIs, which are implemented in Gecko.

This means Gecko provides the sole gateway to the mobile device and underlying services.

The only way to access device hardware functionality is to make a Web API call through Gecko

There is no native API and there are no other routes so no back doors to bypass this mechanism and interact directly with the hardware or access low-level software layer.

Sandboxing and Security

So we can see from this diagram that sandboxes use IPC as the trust boundary for communications to the parent process.

Each app aka child process communicates to the parent process using this trust boundary.

Firefox OS and Linux desktop Firefox use the same implementation of sandboxing

Lets take another look

Ok so now lets take another look at all the layers together

We can see the gecko parent / child relationship stated at the higher levels and note how communication to the lower levels need to go through the permissions manager to gain access to lower levels all of which lives in the Gecko layer

Hopefully by this time in the talk the layers of FirefoxOS and the need for separation is starting to make sense?

Now that we have covered the layers and there communication process lets look into the Linux Kernel and some of the components utilized.

So what parts of the kernel?

Derived from Android (ASOP)Uses libraries from Android (GPS, camera) Has extra Mozilla componentsThese changes to ASOP are not upstreamed unique to FireFoxOS projectVery basic Linux Kernellibusb, bluez and others OSS libraries

Gonk consists of a very small linux kernel that borrows a lot from ASOP as it is effectively an android derived kernel IT is a very basic kernel and does not use all parts of ASOP and also contains certain parts that are Mozilla specific to ensure the boot to gecko process The kernel and several of the user space libraries are common open-source projects: Linux, libusb, bluez, OpenGLES...

Some of the other parts of the HAL are shared with the AOSP: GPS and the camera for example. You could say that Gonk is a very simple Linux distribution with a focus on small memory footprint

Basically, Gonk is a port of Gecko

Gonk is a porting target of Gecko for FireFoxOSGecko has full control over GonkDifference in the exposure of interfaces Two examples telephony stack and display frame buffer where Gonk has full accessThis is not the same for FireFox Browser

Ok so basically we can explain Gonk now in one sentence... Gonk is a porting target of Gecko;

That is, there's a port of Gecko to Gonk, just like there's a port of Gecko to OS X, Windows, and Android. Since the Firefox OS project has full control over Gonk, we can expose interfaces to Gecko that can't be exposed on other operating systems.

An example, Gecko has direct access to the full telephony stack and display frame buffer on Gonk, but doesn't have this access on any other operating system what I mean here is that the port of Gecko for Windows for example does not have nor requires this access.

Linux Kernel and OEMs

Devices will have OEM drivers and firmware to address specific device hardware needs Vendors can modify the kernel and upstream those changes on their own schedule OEM's can also create device drivers and firmware which are not upstreamed

As well as having a Linux Kernel in Gonk which is covered under the Mozilla Public License there are also components that relate to the specific device the OS is being ran on

The OEM drivers and firmware are largely proprietary and relate to the device itself and are not held to the same license schedule as the Gonk Kernel itself

It is important to re-iterate at this point that the bootstrapping process within OEM devices is highly device-specific and therefore may and can and more then likely will be proprietary.

Implementing changes in GONK

Due to unique nature of mobile devices custom components may/will be requiredGonk can be extended in HAL and init and additional firmware/drivers addedAnything added in HAL etc will need to have an inter-process communication channel between actors

So we have discussed certain aspects of the FireFox OS Architecture and also certain components of Gonk we should take a look at what is the process when people/companies need to make changes to Gonk

When specific functionality is required in Gonk this needs to be added by the ODM/OEM/Company/human aka you

This means that the GONK will need to be extended and the HAL files modified to expose new functionality for access to specific device functions/requirements

And an important part of this process is designing and implementing the interprocess communication between layers on the device

Integrating with Gecko

You might expose hardware functionality not currently accessible via Web APIs in GeckoYou first expose functionality in Gonk then you modify Gecko Source to extend the Web APIsThis allows access to the functionality required by the service-level daemon

In order to integrate the lower levels in Gonk to Gaia through to Gecko after you have exposed the new functionality in Gonk you need to modify the Gecko Source code to extend the Web APIs to expose the new functionality

An important part of this is designing the inter-process communication so new functions can work inbetween the areas on the stack

Licensing Issues

OEMs must sign licensing agreements with component suppliersWhy?

Due to proprietary components (drivers etc) specific to that hardware device

Licensing issues.... well not really issues per say as in how Mozilla handles proprietary code

OEMs must sign licensing agreements with component suppliers to ensure that all code/drivers /firmware being used is allowed to be used etc as this talk does not dive deep into licensing I dont think we should go to much more deeper into the topic then this... but lets have a quick look at who is responsible for what in Gonk

Who is responsible for Gonk

MozillaMaintains source repositories and support files Repositories include the base Linux kernel and hooks into GeckoMaintained under the Mozilla Public License https://www.mozilla.org/MPL/

As discussed GONK is really a derived version of Android OS with some Mozillian touches

Due to this Mozilla maintains the source repositories and any needed support files

It is maintained as an Open Source project under the Mozilla Public License, Therefore the project can be forked/cloned etc

The upstream process is not as straight forward as one might like it to be this is due to the fact that there are also third party components that will not be included in the Mozilla repos

As with Android it is at the discretion of Mozilla what it wishes to accept into the Mozilla lets say raw Gonk and you could say Mozilla tries to maintain a vanilla Gonk distro to make it easy for people to add/extend

Third Parties and Gonk

OEMs and ODMs Building, compiling, testing, certifying, distributing Firefox OS device imagesEnsuring seamless Gonk to Web API (Gecko) integration callsDevice hardware functionality

The land of mobile devices can sometimes be a tricky one to mitigate due to device chipsets etc

This sees other third parties responsible for components within Gonk aka the needed drivers/firmware for the specific hardware of the device they are releasing with FireFoxOS

At this level the changes and drivers created do not need to be upstreamed and companies can effectively add their own drivers without the need to push up to Mozilla or out to the general public

Therefore it falls to Third Parties device owners to maintain their own build and ensure seamless communications with Gonk and Gecko

So the blockers, you say?

Upstream process is not guaranteedThere is proprietary drivers that will never see the light of the upstreamFragmentation starts to occur Each OEM, Device owner, person can maintain their own fork of FireFoxOS

Always limitations :/

Good example: mobile phones It's up to the telcos to push out an upgrade 1.1 is the main version in the wild yet Mozilla is at version 2 already :/

Hard to provide community support

Frustrating to users they can see upgrades discussed online but not on their phone

Makes you want to...

Flash your own device and maintain your own phone distro to stay aheadAnnoying maybe? But hey at least with FireFoxOS you can if you so choose...https://developer.mozilla.org/en-US/Firefox_OS/Installing_on_a_mobile_device

The good thing about FireFoxOS is that you can simply flash your phone and get the latest updates

There is various documentation on the Mozilla Developer pages on how to flash your device as it is an android derivative it requires the same build tools that needed to flash android devices

You can flash your device with the standard Mozilla FireFoxOS images apart from that Companies can also make there images available for you to flash at this point in time I believe that only GeeksPhone are supporting their own images as well as APC though APC is not for a phone device but is a port for a small pc device

Make it your own

Based on Android kernel (ASOP)This (hopefully) makes it easier to port existing device drivers, firmware, service daemons, and other componentsSupported devices list can be found in the repo B2G/config.shIf yours is not there add it?

Most of the work that people contribute to has been to get FireFoxOS running across different devices The list of supported deevices can be found in the github repository at B2G/config.sh If you want to roll it onto a device that is not listed you can start working on it in your own time to add the deviceAt the moment Mozilla Developer devices are the Flame and Geeksphone iterations apart from this you can install the FireFoxOS simulator which runs inside of FireFox Browser and is also integrated into Mozillas new Browser IDEz

How to contribute

The b2g process is defined in Gonk Modifications to b2g source code can be made https://github.com/mozilla-b2g/gonk-misc

The source files for FireFoxOS is kept on github

The actual build process starts with obtaining a copy of the Firefox OS (or B2G) software, usually by creating a Git clone of the B2G project. The build configuration will both obtain copies of all the source code which is to be built and create the .config file that specifies variables for the build.

You can also look in bugzilla for bugs to squash All bugs are handled through BugZilla as with all Mozilla projects

Most of the day to day work done on Gonk involves porting the system to different boards and make sure Gecko can work well on different devices.

There are weekly call ups on Mozilla Air most of these are contained to mozillians paid and volunteers so not so open to the everyday public

Cool toys and future projects

So it is important to remember that FireFoxOS has been out for about a year now so it is still a relative baby on the marketThere have been some exciting news come out which has seen it move from just mobile phones to other so called portable devicesPanasonic announced a partnership with Mozilla to use FireFoxOS to support smart Tv'sThe APC team developed the paper and rock mini/portable PCs they maintain there port of FireFoxOS for the device on githubThere is also a FireFoxOS tablet that is being worked on though no specific release datesMozilla has also announced a ChromeCast competitorThere is also a flash for Raspberry Pi Lost of new projects are coming out regularly

So more Mobile Platforms?

Choice is GoodBeing a Monopoly is bad for allLinux was made for embedded devices

Go forth and play with FireFoxOS

Roll your own distro with the Yocto ProjectCheck out Tizen