It is the user interface of the Firefox OS platform. Anything drawn to the screen once Firefox OS is started up is a product of the Gaia layer. Gaia implements the lock screen, home screen, and all the standard applications you expect on a modern smartphone. Gaia is implemented entirely using HTML, CSS, and JavaScript. It interfaces to the underlying operating system through open Web APIs. It facilitates installation of Third party applications.
2.2 GECKO
Gecko is the open source browser engine designed to support open Internet standards such as HTML, CSS, the W3C DOM, XML, JavaScript, and others. Gecko provides the foundation needed to display content on the screen, including a layout engine and a complementary set of browser components. Gecko lies at the heart of Mozilla and Firefox browsers, as well as others, powering all of the individual components and provides cross platform support.
2.3 GONK
Gonk is the lower level operating system of the Firefox OS platform, consisting of a Linux kernel and user space hardware abstraction layer (HAL). The kernel and several of the user space libraries are common open-source projects: Linux, libusb, bluez, and so forth. Some of the other parts of the HAL are shared with the Android project: GPS, camera, and others. One can say that Gonk is a very simple Linux distribution. 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 Mac 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. For 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.
3. Boot Loader Process
The Boot Loader Process involves the
� Bootstrapping
� Linux Kernel
� User Space Architecture
3.1 Bootstrapping
After turning on a b2g phone, execution starts in the primary boot loader. From there, the process of loading the main OS kernel happens in the usual way: a succession of higher-level boot loaders bootstrap the next loader in the chain. At the end of the process, execution is handed off to the Linux kernel. The boot loaders usually show the first "splash screen" seen during device boot, which usually displays a vendor logo. The boot loaders implement flashing an image onto the device. Different devices use different protocols. By the end of the bootstrapping process, the modem image is usually loaded and running on the modem processor.
3.2 Linux Kernel
The Linux kernel(s) in Gonk is reasonably close to upstream Linux. Vendors also modify the Linux kernel and upstream those modifications on their own schedule. But in general, the Linux kernel is close to stock. At the end of kernel startup, a user space "init" process is launched, like in most other UNIX-like OS. At this point in execution, only a ramdisk is mounted. The ramdisk is built during the b2g build process, and consists of critical utilities (like init), other startup scripts, and loadable kernel modules. The init process in Gonk handles mounting the required file systems and spawns system services. After that, it stays around to serve as a process manager. One key task the init process handles is starting up the b2g process; this is the core of the Firefox OS operating system.
Fig.2 Sample Code to read the battery state
3.3 User Space Architecture
Fig.3 Firefox OS user space architecture
The b2g process is the primary system process. It runs with high privileges; it has access to most hardware devices. b2g communicates with the modem, draws to the display frame buffer, and talks to GPS, cameras, and other hardware features. The rild process is the interface to the modem processor. rild is the daemon that implements the Radio Interface Layer (RIL). It's a proprietary piece of code that's implemented by the hardware vendor to talk to their modem hardware. In Firefox OS, the rild client is the rilproxy process. This acts as a dumb forwarding proxy between rild and b2g.The mediaserver process controls audio and video playback. Gecko talks to it through an Android Remote Procedure Call (RPC) mechanism.
Some of the media that Gecko can play (OGG Vorbis audio, OGG Theora video, and WebM video) are decoded by Gecko and sent directly to the mediaserver process. Other media files are decoded by libstagefright, which is capable of accessing proprietary codecs and hardware encoders. The netd process is used to configure network interfaces. The wpa_supplicant process is the standard UNIX-style daemon that handles connectivity with WiFi access points. The dbus-daemon implements D-Bus, a message bus system that Firefox OS uses for Bluetooth communication.
4. Hardware Abstraction Layer (HAL)
The Gecko hardware abstraction layer 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. These APIs are implemented on a per-platform basis inside the Gecko HAL itself.
Fig.4 Vibration API of Gecko HAL
The above code snippet turns the default vibrator device on/off based on the pattern specified by |pattern|. Each element in the pattern is the number of milliseconds to turn the vibrator on or off. The first element in |pattern| is an "on" element; the next is "off", and so on. If |pattern| is empty, any in-progress vibration is canceled. Only an active window within an active tab may call Vibrate; calls from inactive windows and windows on inactive tabs do nothing.
Fig.5 Battery Parameter API of Gecko HAL
The above code informs the battery backend there is a new battery observer.
Fig.6 Battery Information API of Gecko HAL
5. Radio Interface Layer (RIL)
There are two related API�s associated with RIL. They are
� Telephony API
� SMS API
5.1 Telephony API
The aim of Web Telephony is to establish a DOM API, which allows web content to dial out and mediate calls, i.e. answer, reject, hold or resume a call.
Fig.7 Direct Telephony Events API
The access to the phone functionality is simply through navigator.mozTelephony. Once there is a reference to that object, then calls can be placed and received using the API as in Fig.7. The Telephony API consists of other dynamic events such as call connection and disconnection.
Fig.8 Call connection & Disconnection API
There is also provision for call receiving and iterating over calls and taking action depending on their changed status.
Fig.9 Call Iteration API
5.1 SMS API
A part of the core functionality in a mobile phone is sending and receiving SMS messages, and that is accomplished through the WebSMS API.
Fig.10 SMS API
6. Run Time Security Model
The Firefox OS runtime security model is designed to:
� Enforce the permissions granted to Web apps.
� Protect the Firefox OS core and content processes from attack by malicious content.
� Ensure that communication channels between the content process and the core process are not used in unintended ways.
The permission controls outlined below are based on the architecture outlined in the Firefox OS architecture overview, as follows:
� The Firefox OS core process, b2g, has very high privileges and has access to most hardware devices.
� Web apps run in a low-privileged content process and only communicate with the b2g core process using IPC, which is implemented using IPDL.
� Each Web API has an associated IPDL interface.
� Firefox OS maintains a central permissions database that stores the permissions granted to each Web app. Permissions are added at installation time, and can only be modified by the permissions manager application.
There is an inherent degree of security offered by the fact that in Firefox OS, all applications are Web apps. There are no strictly binary ("native") applications installed by the user, and all system access is mediated through the Web APIs. In addition, there's no direct access to the file system; files stored on the SD card are exposed using Web APIs as well. Because of this, the key potential threats to the underlying operating system are:
� Memory corruption or logical errors in Gecko that lead to arbitrary code execution.
� Similar faults in the operating system itself (the kernel and daemons) that lead to arbitrary code execution.
� A compromise of the software updates mechanism.
� Hijacking of a Web application using XSS or memory corruption (for example).
� Vulnerability in IPDL.
Mitigation of code execution threats is introduced by taking the following steps:
� Gecko is hardened against attack.
� Web content is run in lower-rights child processes in order to reduce the impact a process compromise introduces. This is the Firefox OS content process.
� The underlying operating system is hardened to make post-exploitation more difficult.
� When available, hardening features of the compiler are used.
The Firefox OS process model is based on the concept of a single core process (the parent process), which has access to all hardware, services, and so forth, and one or more content processes (the children), each of which has only enough access to the system to communicate with the parent process.
In case of vulnerability in a content process, the operating system limits the impact by denying system level resource access to the low-privilege content process. Compromising the core process is equivalent to complete compromise of the operating system.
7. Future Implementations
The future improvements that are planned for the Operating System include
� Finer level of separation between various software components, such as the core processes components. For example, segregating the WebGL graphics pipeline would allow tighter sandboxing of the Firefox OS content processes.
� Implementation of Full Disk Encryption (FDE)
� Secure booting Support and enhancement to fast boot
� Updating Operating System using
1. Firmware Image
2. Over The Air (OTA)
OTA updates can be performed wirelessly almost similar to Android OS update. If an OTA upgrade fails (due to a power issue, hardware failure, or the like), the device may become "bricked"; that is, it may no longer be able to run the operating. In that scenario, the device is connected to a computer using a USB cable and the fast boot loader is used to install a firmware image.
