FirefoxOS and its use of Linux (a deep dive into Gonk architecture)


Published on

Talk given at LinuxCon America in Chicago 2014 about FireFoxOS and its use of Linux Kernel

Published in: Internet
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Little introduction to me
    My name is Aimee Maree Forsstrom
    Been using Linux since Debian Potato
    Contributed to various OSS Web projects
    Mentor Children and have taught Python, Scratch, Alice, PHP, HTML/CSS, JavaScript and iOS
    Contributed 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
  • By now you would of heard about FireFoxOS from Mozila
    It has been in the wild now for just over a year
    First started life as the B2G project aka Boot 2 Gecko
    It is still reffered to as B2G in github repos and documentation on the web
    It is Mozillas attempt at entering the mobile platform space
    It 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 footprint
    It 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
  • 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
  • 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 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 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
    It’s 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.
  • 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
  • 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.
  • As mentioned Gaia is where the application will live
    The 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 Gecko
    It is then at this point that communication with Gonk is initiated
    Gonk will then communicate directly to the hardware device
  • 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
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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
  • 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.
  • 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.
  • 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
  • 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.... 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
  • 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
  • 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
  • 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
  • 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/
    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 device
    At 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
  • 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
  • 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 market
    There have been some exciting news come out which has seen it move from just mobile phones to other so called portable devices
    Panasonic announced a partnership with Mozilla to use FireFoxOS to support smart Tv's
    The APC team developed the paper and rock mini/portable PCs they maintain there port of FireFoxOS for the device on github
    There is also a FireFoxOS tablet that is being worked on though no specific release dates
    Mozilla has also announced a ChromeCast competitor
    There is also a flash for Raspberry Pi
    Lost of new projects are coming out regularly
  • FirefoxOS and its use of Linux (a deep dive into Gonk architecture)

    1. 1. FireFoxOS and its use of Linux Aimee Maree Forsstrom @aimee_maree
    2. 2. What is FireFoxOS Mobile Operating System developed by Mozilla to power mobile devices Utilises Linux, Android and Gecko (FireFox browser engine)
    3. 3. FireFoxOS Architecture Layers
    4. 4. Gaia User interface application for Firefox OS devices Web application running atop Firefox OS Comes with some standard applications Isolated from Gonk communicates through Gecko
    5. 5. Gecko Application run time Collection of API's for hardware access Renders Web Content ACLs and permissions are controlled in Gecko
    6. 6. Gonk Linux Kernel Device Drivers Hardware Abstraction Layer Isolated from Gaia Communicates through Gecko/B2G Magic Black Box
    7. 7. Lets dive deeper into Gonk
    8. 8. How Gonk handles a request
    9. 9. How the layers communicate
    10. 10. HAL Not exposed directly to JavaScript code C++ API accessible to higher levels of Gecko Gecko communicates with Gonk directly through the HAL This communication is run in a sandbox environment
    11. 11. init process Will execute processes defined in init.rc and the successor init.b2g.rc Launches userspace init process Once the init process is launched, Linux kernel handles system calls from userspace, and interrupts from hardware device Hardware features are exposed to userspace through sysfs
    12. 12. BootStrap
    13. 13. Inter-Process Communication Inter-process Communication Protocol Definition Language Developed by Mozilla C++ code to pass messages between processes or threads in a secure way Apps communicate with service-level daemons via IPC
    14. 14. IPC Architecture
    15. 15. IPC Parent <> Child relationship
    16. 16. Hardware Access Apps access hardware only via Web APIs Gecko is the sole gateway to mobile device No “native” API no other “back doors” Apps are ran in a sandboxed mode
    17. 17. Sandboxing and Security
    18. 18. Lets take another look
    19. 19. So what parts of the kernel? Derived from Android (ASOP) Uses libraries from Android (GPS, camera) Has extra Mozilla components These changes to ASOP are not upstreamed unique to FireFoxOS project Very basic Linux Kernel libusb, bluez and others OSS libraries
    20. 20. Basically, Gonk is a port of Gecko Gonk is a porting target of Gecko for FireFoxOS Gecko has full control over Gonk Difference in the exposure of interfaces Two examples telephony stack and display frame buffer where Gonk has full access This is not the same for FireFox Browser
    21. 21. 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
    22. 22. Implementing changes in GONK Due to unique nature of mobile devices custom components may/will be required Gonk can be extended in HAL and init and additional firmware/drivers added Anything added in HAL etc will need to have an inter-process communication channel between actors
    23. 23. Integrating with Gecko You might expose hardware functionality not currently accessible via Web APIs in Gecko You first expose functionality in Gonk then you modify Gecko Source to extend the Web APIs This allows access to the functionality required by the service-level daemon
    24. 24. Licensing Issues OEMs must sign licensing agreements with component suppliers Why? Due to proprietary components (drivers etc) specific to that hardware device
    25. 25. Who is responsible for Gonk Mozilla Maintains source repositories and support files Repositories include the base Linux kernel and hooks into Gecko Maintained under the Mozilla Public License
    26. 26. Third Parties and Gonk OEMs and ODMs Building, compiling, testing, certifying, distributing Firefox OS device images Ensuring seamless Gonk to Web API (Gecko) integration calls Device hardware functionality
    27. 27. So the blockers, you say? Upstream process is not guaranteed There is proprietary drivers that will never see the light of the upstream Fragmentation starts to occur Each OEM, Device owner, person can maintain their own fork of FireFoxOS
    28. 28. 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
    29. 29. Makes you want to... Flash your own device and maintain your own phone distro to stay ahead Annoying maybe? But hey at least with FireFoxOS you can if you so choose... US/Firefox_OS/Installing_on_a_mobile_device
    30. 30. Make it your own Based on Android kernel (ASOP) This (hopefully) makes it easier to port existing device drivers, firmware, service daemons, and other components Supported devices list can be found in the repo B2G/ If yours is not there add it?
    31. 31. How to contribute The b2g process is defined in Gonk Modifications to b2g source code can be made
    32. 32. Cool toys and future projects
    33. 33. So more Mobile Platforms? Choice is Good Being a Monopoly is bad for all Linux was made for embedded devices Go forth and play with FireFoxOS Roll your own distro with the Yocto Project Check out Tizen