eLBaaS Overview

A champion Operating System for a champion product

Building an IoT product can be challenging. Often an IoT solution requires a gateway sitting in the middle between low-end sensors and the cloud. An IoT gateway need to be secure and when it is part of a product it can be a weakest link of the deployed infrastructure if it is not well protected. To quote Bruce Schneier, A security system is only as strong as its weakest link (there could be few variants of this quote which ultimately means the same thing and I'm referring to Bruce Schneier cause I got to know this quote from his book Practical Cryptography). Introducing a weakly secure device can lead to serious compromise even on a very well protected infrastructure. So before introducing an IoT solution in any infrastructure, security of the IoT solution need to be validated.

A product team's primary focus is developing the core application that reflects all the product features. Below figure outlines such organization ( although application is part of the Operating System but it is shown separately based on the concern of the product ). This organization can be divided into three layers. Layer-1 is the hardware layer. A hardware can be a very well known single board computer like RaspberryPi, Beaglebone or a custom board based on a NXP processor. Layer-2 is the operating system (OS) -- an OS is a collection of softwares. The core component of an OS is the kernel. Along with the kernel this layer also consist of a bootloader ( GRUB/U-Boot/Coreboot ) etc. Bootloaders and the kernels are hardware dependent - they need to be configured or sometimes need to be extended if there is no support for a custom hardware board. Finally layer-3 where the application resides - the application can be seen as a business layer too. All the features that the product are basically lands in this layer.

While building an IoT solution ( or an embedded Linux based product ) the focus of a product team is at the application layer. Building and maintaining an OS is a time consuming, repetitive and must be maintained task. The development team focusing at the application layer can make sure the security of the application but maintenance and securing the underlying OS is different. The OS components are developed by different development teams so maintenance of the those components require close follow-up with a particular community. Sometimes it may require specialized skills and know-how of tools like. YOCTO, Buildroot. In such case the application development speed can be greatly reduced due to the integration and maintenance effort required by the engineering team. In the YOCTO world it is also known as BSP maintenance. This additional expertise and know-how also put effect on development costs. Finding the necessary skills can be a huge hurdle too. The best way to speed up the process is to rely on an existing solution. To address such limitations and to offload the burden of building and maintaining the OS we are offering eLBaaS. eLBaaS can be controlled by the product management team as well as the development team. A product management team can use it for creating releases (software) and the development team can be benefited by utilizing the capability of creating a custom OS build configurations without really knowing the details of YOCTO.

The naming of eLBaaS gives the impression that the solution inherits the SaaS delivery model. In recent years SaaS proven to be a very lucrative approach for delivering various software driven solutions. So far there is no such solution for YOCTO and eLBaaS sets up an example of how a SaaS based approach can be used to deliver a very non traditional tools like YOCTO. Therefore making it easy for everyone to understand particulary people who are involved with product management.

OS maintanance and product Security

To quote Bruce Schneier again Security is not a product, it is a process. Maintaining a process can be expensive. Often a process is repetitive therefore a good candidate for automation. An automated process is best maintained through a pipeline. And this is another aspect that eLBaaS is trying to address. Taking the maintenance overhead out of the product team allows them to focus more at the product development.

How or why does the solution work?

Lets recall the three layer diagram. As it shows the business logic of the application are mostly at the application layer which indicates the OS layer is independent of the application layer. This essentially indicates that the same OS can be used in different products. Lets try to depict the scenario. A hypothetical scenario where each of the team is using different hardware at layer-1 and different application at layer-3. To adopt the hardware level changes the eLBaaS pipeline allow its users to customize the kernels and the bootloaders. These are the main two components in board bring-up for custom boards. Apart from that the other components of the OS are same.

Rather maintaining three different OS for three different products, eLBaaS offers maintenance of all the OS packages ( components ) and letting users to pick which one they need. The choice starts from picking the Yocto version. It is possible to pick a particular Yocto version. Currently, RPi based processors are supported ( Beaglebone and NXP will be added soon). Each of these Yocto version for each of these processors are maintained by eLBaaS team internally and then offered to the end users. The infrastructure offers sandboxed build environment for each product basing the same point of source as the team would have used if they were setting up on their own.

When a new security fix is coming for the Linux it will be integrated into the Yocto release and will be ready for integration by the product team. If a new version of a package is required by a team and that is not available, it can be requested manually and a support engineer will take care of the request.

Custom hardware board requires a board bring up solution however eLBaaS does not offer such solution as part of eLBaaS. Typically board bring-up require changes in the kernel ( Linux ) and/or at the bootloader. eLBaaS allows its users to upload a custom kernel or a custom bootloader during creation of a build configuration (feature to be integrated soon!). During this stage our support team will also help in any regard. This typically needs to be done once.

Apart from providing any specific integration solution into the pipeline support team will also help to get any custom configuration at the OS level if required. Although the three layer diagram shown above isolates the application from OS which is the split is based on the development perspective but in reality the application is shipped as a part of the OS. As long as the product lives the security of the product should be maintained. The proposed solution solves the problem in a most effective way by utilizing resources, avoiding repetitive work and providing development team a user friendly interface where they don't need to know the details of YOCTO and still can achieve the same.