Open Source
Matter SDK: Contribution to Tizen Platform Support
Introduction & Motivation
Samsung, as a member of Connectivity Standards Alliance (CSA), is actively participating in the development of the Matter1 specification and its reference implementation, the Matter SDK2. In our IoT products, we are using not one, but many different platforms. This is why we are so interested in active participation in the Matter SDK development. We want to make sure that the Matter SDK is available for all platforms that we are using, so that we can deliver the best user experience to our customers.
For the brief introduction to the Matter project, please refer to the previous blog article "CSA Releases Matter 1.0 Specification and SDK for Smart Home IoT Standardization"3.
1 https://csa-iot.org/all-solutions/matter
2 https://github.com/project-chip/connectedhomeip
Tizen Platform
The main area of contribution of Samsung to the Matter SDK is Tizen platform support. However, we are also contributing to the SDK in other areas, such as Android and Linux.
Tizen, as a platform, very heavily resembles Linux. It is based on the Linux Kernel and uses many of the same technologies, such as D-Bus and systemd. However, its key difference is the security-oriented design. In order to preserve the security of the platform within the Matter application, we are not running the Matter application as a system process, but as a sandboxed application. This specific design requires some special handling in the Matter SDK.
Tizen Matter Lighting Application
In order to simplify the integration of Matter into Tizen applications, we have created an example application that can be used as a template for other applications. This example provides a correct Tizen application manifest file with all the privileges and features which are needed for the Matter application to run correctly. Also, we have integrated Tizen Studio CLI tools into the Matter SDK build system, so that the application can be built and installed on the Tizen device with much less effort. This integration adds support for automatic generation of the Tizen application author certificate (for development only) and adds this certificate to the developer signing profile. In the final step, the application is packaged into the Tizen package file (TPK) and signed with previously generated signing profile. This way, the developer can easily install and test the application on the Tizen device without any additional prior knowledge about the packaging and signing process4.
4 https://github.com/project-chip/connectedhomeip/blob/master/examples/lighting-app/tizen/README.md
Figure 1. Tizen Matter Lighting Application
Tizen on QEMU for CI/CD
Agile development requires fast and reliable CI/CD pipeline. In order to achieve this, we are using QEMU to emulate Tizen device on the Matter SDK CI/CD workflow. This allows us to run the example Tizen Matter Application and unit tests on real Tizen ARMv7-based IoT image without the need to have the physical device connected to the CI/CD server.
In order to allow Tizen to run on QEMU, we had to compile the Tizen kernel image with the support for QEMU VirtIO devices. That is the only customization that we had to do in order to make Tizen run on QEMU. The Tizen image itself used in that setup is based on the stock image downloaded from the Tizen download server. However, we have added a few modifications to the stock image, so that it can be used in the CI/CD workflow in a non-interactive way. These modifications include:
1. Mounting the /opt directory as an overlay filesystem with a backing-store on the tmpfs filesystem. Such setup makes the Tizen application be installed in the non-persistent storage, which is discarded after the system reboot. This allows for running tests in a deterministic way on every QEMU start.
2. Auto-detection and auto-mount of the specially prepared ISO image with the Matter SDK unit tests or custom test scripts.
3. Detection of the auto-run script on the ISO image and automatic execution of this script in order to run the unit tests without user interaction.
The setup is based on Docker, so it can be easily adopted by other projects which are not necessarily related to the Matter SDK, to test their software solutions on Tizen platform.
Tizen Native API
Tizen application integrates with the system using various Tizen Native APIs which internals are heavily based on glib2 (e.g. for D-Bus communication). In order to integrate Matter SDK with the Tizen Native APIs, we have to process events associated with glib2 main event loop. In most cases, this is done by running global main event loop which operates on the global main context. However, Matter SDK cannot be integrated in this way, because it would acquire the global main context and, in some cases, it would prevent the application from running correctly. To solve this problem, we have created a separate glib2 main context and attached all the events associated with used Tizen Native APIs to this context.
Having a multi-threaded SDK, where the Matter SDK event loop is running on one thread and the Tizen Native APIs are running on another thread, requires proper synchronization of the access to the Matter SDK internal data structures. Otherwise, we might face data races that might lead to security vulnerabilities, which in the worst case scenarios might cause security breach of the whole IoT home network. This data access synchronization is done by acquiring the Matter stack lock before accessing the data. However, in very rare cases, this can cause a deadlock. It can happen when the Tizen Native API uses callbacks to notify the application about some event and at the same time it uses its own internal mutex to protect its data structures. See the sequence diagram below for a possible deadlock scenario.
Figure 2. Deadlock between Matter SDK and Tizen Native APIs
This is a classic example of mutex lock inversion. In order to prevent this, we need to make sure that the Matter SDK stack lock is always acquired before the Tizen Native API lock. Since the Matter SDK code is under our control, we have achieved that by acquiring the Matter SDK stack lock before processing events on the glib2 event loop thread. This way, we can guarantee that the locks will be acquired in the correct order.
The lock inversion problem is not specific to the Tizen Native APIs. Linux platform also uses glib2 for D-Bus communication and it is also affected by this problem.
Tizen Bluetooth LE Support
In Matter, Bluetooth is used for device discovery and commissioning. The Matter specification requires that the device will advertise itself as a Bluetooth LE only (no BR/EDR support), peripheral device. However, Tizen Bluetooth API did not meet this requirement. Tizen Bluetooth API was designed to advertise the device as a dual mode device (Bluetooth LE and BR/EDR support). Such configuration prevented Matter-enabled controllers to properly recognize Tizen Matter devices. To solve this problem, we have patched the Tizen Bluetooth API to allow application developers to select the advertising mode. New Tizen Bluetooth API is available since Tizen 7.5.
DNS-SD Enhancements for Tizen
In Matter, DNS-SD is used for device discovery during the commissioning process. Matter SDK implements DNS-SD by providing common upper layer logic and platform-specific implementation of the DNS-SD browse, public and resolve APIs. In most platforms, the DNS-SD browse process notifies the application about the end-of-browse event. However, in Tizen, the DNS-SD browse process does not provide such information. Lack of this notification makes it impossible to properly implement the DNS-SD browse process. As a result, Tizen implementation of the DNS-SD browse process was not able to detect more than one device.
To remedy this problem, we have proposed a small change to the common Matter SDK DNS-SD API. The change extends the DNS-SD browse callback with the explicit notification about the end-of-browse event. This way, the Tizen implementation can call the DNS-SD browse callback every time it discovers a new device. Then, after a period of inactivity, it can notify the Matter SDK core that the browse process has finished.
With this small enhancement, the Tizen implementation of the DNS-SD browse process is able to detect more than one device. This way, we can implement the fully functional Matter controller on Tizen platform.
Code Quality and Style Improvements
As a part of our contribution to the Matter SDK, we are also working on code quality and style improvements. We have fixed many issues reported by the flake8 static code analysis tool for Python. In order to prevent future issues, we have integrated the flake8 tool with the Matter SDK CI/CD workflow. This way, we can make sure that the code quality and style is maintained at the highest level.
Another important contribution in terms of code quality is the integration of the include-what-you-use tool with the Matter SDK. This tool is used to check the correctness of the C++ include statements. The correctness of the include statements is very important for the C++ code, because unneeded includes can significantly affect the compilation time during the development process where files are often modified. The proper order of the include statements ensures that the header files are self-contained, so anyone can easily include them without the risk of compilation errors and the struggle of finding missing dependencies.
Plans for The Future
We are planning to continue our work on the Matter SDK Tizen platform support improvements. One of the tasks is to add full support for Thread network commissioning, both for end devices and for controllers running on the Tizen platform. This will allow us to create a fully functional Matter sleep devices (end-devices) as well as Matter-enabled Thread Border Routers (TBR).
Another important task is to add support for btvirt (Bluetooth Virtual Device) to Matter SDK CI/CD workflows for Linux and Tizen platforms. This will allow us to validate BLE commissioning on every pull request, because currently we are only able to validate that by performing manual tests on real devices. Lack of automated tests for BLE commissioning from time to time causes regressions in this area.
