The M300 SDK v7.0 is based on Linux 5.10.186, which is approximately equivalent to the earlier Ubuntu 20.04 LTS version, making it a relatively stable release. As time progresses, research into various Linux kernel versions has deepened, uncovering system vulnerabilities and network flaws. However, for the M300 SDK as an embedded system, our focus remains primarily on unstable kernel configurations and third-party software/libraries configured in Buildroot, as these configurations may lead to instability in long-term operation of Linux due to user-written code or running certain services.For kernel configuration, this article demonstrates the use of the LTP tool to detect whether the current version has issues; for Buildroot, we use cve-bin-check to detect vulnerabilities and briefly explain how to address these issues.LTP Tool OverviewLTP stands for Linux Test Project, which uses its internal built-in module tst_kconfig to check whether Linux kernel configuration options (KCONFIG) meet testing requirements.The M300 SDK has LTP functionality built-in, but due to the large size of the standard LTP, the built-in features are not complete. To use this tool correctly, we still need to download the code from https://github.com/linux-test-project/, compile it using the SDK’s MIPS GCC, and finally upload the executable file to the development board. LTP has numerous test cases, and the overall software after compilation reaches 1.6G, so it is best to configure the eMMC partition for storage.LTP tests the system through built-in test cases, using these cases to determine:
-
Whether a certain kernel feature is enabled (i.e., the presence of a specific CONFIG_XXX)
-
Whether a certain system call is available (based on kernel configuration)
-
Some tests can only run when debugging, auditing, network features, etc., are enabled
Testing the System
LTP supports a wide range of tests, and currently, we mainly focus on whether the kernel configuration is secure. Therefore, the testing target is primarily concentrated on system calls, running on the development board:./runltp -f syscalls
LTP begins to run for an extended period based on pre-configured test cases. On the initially compiled system of the SDK (without modifying any configurations), this run produces the following crashes:
The crashes mainly occur on io_uring, and the operating system crashes when LTP executes the second test case for io_uring.To address this crash, we run make kernel-menuconfig in the SDK root directory and look for the io_uring configuration:
It can be seen that the SDK has predefined the IO_URING configuration as enabled, but the IO_URING feature only began to mature in version 5.10 and became stable after 5.15. Therefore, there may still be instability in the current version of the SDK. After disabling this option, we run LTP again for testing, and the tests ultimately complete successfully.Kernel Option DecisionsIn addition to the issues identified by LTP, we also need to analyze the current SDK’s kernel configuration in detail, categorizing potential problematic configurations into three types:1. Configurations that have little to no impact on performance when modified2. Configurations that have some impact on performance but provide higher security3. Configurations that have a significant impact on performanceConsidering that the M300 is an embedded system, we should focus on the first two aspects for configuration. After completing the configuration, LTP functional testing and stress testing should be conducted to check for any significant impact on performance.Due to space limitations, we will only provide a brief example of type 1:
- CONFIG_FORTIFY_SOURCE, compiler checks for unsafe functions
- CONFIG_BUG_ON_DATA_CORRUPTION, crashes immediately after detecting memory unit corruption to avoid being injected
- CONFIG_SNY_COOKIES, defense against SYNC FLOOD network attacks
- CONFIG_DEFAULT_MMAP_MIN_ADDR, increases the minimum address for user-space program mmap
Stress Testing ToolsAfter making the above configurations, in addition to running LTP for configuration testing, the system also needs to undergo stress testing. The SDK comes with the stress_ng tool. Run make buildroot-menuconfig under the SDK, and underTarget packages → Debugging, profiling and benchmark, check stress_ng:
After saving, compile and flash the firmware, log into the development board, and execute:
stress-ng –cpu 2 –vm 2 –vm-bytes 128M –io 1 –timeout 600s –metrics-brief
and compare the results with those before the configuration.Introduction to cve-bin-toolFor vulnerability detection of the filesystem built with Buildroot, the standard Linux kernel can configure cve attributes to automatically check during compilation. However, due to the needs of embedded systems, this part has been trimmed from the SDK. Interested readers can install it on Ubuntu themselves; it is a set of Python scripts. After successful installation, you can check using the following command:
cve-bin-tool -o report.html -f html ~/ingenic-linux-kernel5.10-m300-v7.0-20240301/out/product/gewu.v10_nand_5.10-eng/obj/buildroot-intermediate/target
After running, cve-bin-tool will automatically generate a report named report.html, which users can use to address vulnerabilities. Due to the significant variability in software customization in Buildroot, we will not elaborate further here. The following image shows the potential issues displayed after testing the standard SDK:
There are still high-risk (score: 9.8) software present