Recently, I have been researching the open source Hongmeng system, but I encountered a problem and it got stuck, which made me not want to eat and drink. In the previous article, Hongmeng System Research No. 4: In the root file system , I encountered a problem:
The reason for this problem is that SELINUX is not enabled when the Linux kernel is compiled. However, after turning on the SELINUX option, I encountered more trouble:
Run /init as init process
random: crng init done
init: init first stage started!
init: [libfs_mgr]ReadFstabFromDt(): failed to read fstab from dt
init: [libfs_mgr]ReadDefaultFstab(): failed to find device default fstab
init: Failed to fstab for first stage mount
init: Using Android DT directory /proc/device-tree/firmware/android/
init: [libfs_mgr]ReadDefaultFstab(): failed to find device default fstab
init: First stage mount skipped (missing/incompatible/empty fstab in device tree)
init: Skipped setting INIT_AVB_VERSION (not in recovery mode)
init: Loading SELinux policy
SELinux: policy capability network_peer_controls=1
SELinux: policy capability open_perms=1
SELinux: policy capability extended_socket_class=1
SELinux: policy capability always_check_network=0
SELinux: policy capability cgroup_seclabel=0
SELinux: policy capability nnp_nosuid_transition=1
SELinux: (dev mmcblk0p2, type ext4) has no security xattr handler
audit: type=1403 audit(1625477182.800:2): auid=4294967295 ses=4294967295 lsm=selinux res=1
selinux: SELinux: Loaded policy from /vendor/etc/selinux/precompiled_sepolicy
audit: type=1404 audit(1625477182.800:3): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295 enabled=1 old-enabled=1 lsm=selinux res=1
audit: type=1400 audit(1625477182.810:4): avc: denied { read } for pid=1 comm="init" name="plat_file_contexts" dev="mmcblk0p2" ino=382 scontext=u:r:kernel:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
selinux: No path given to file labeling backend
selinux: selinux_android_file_context: Error getting file context handle (No such file or directory)
audit: type=1400 audit(1625477182.820:5): avc: denied { read } for pid=1 comm="init" name="product" dev="mmcblk0p2" ino=35 scontext=u:r:kernel:s0 tcontext=u:object_r:unlabeled:s0 tclass=lnk_file permissive=0
audit: type=1400 audit(1625477182.820:6): avc: denied { read } for pid=1 comm="init" name="vendor_file_contexts" dev="mmcblk0p2" ino=1259 scontext=u:r:kernel:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
audit: type=1400 audit(1625477182.820:7): avc: denied { read } for pid=1 comm="init" name="etc" dev="mmcblk0p2" ino=27 scontext=u:r:kernel:s0 tcontext=u:object_r:unlabeled:s0 tclass=lnk_file permissive=0
init: execv("/system/bin/init") failed: Permission denied
audit: type=1400 audit(1625477182.840:8): avc: denied { execute } for pid=1 comm="init" name="init" dev="mmcblk0p2" ino=156 scontext=u:r:kernel:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
audit: type=1400 audit(1625477182.860:9): avc: denied { read } for pid=1 comm="init" name="libbacktrace.so" dev="mmcblk0p2" ino=770 scontext=u:r:kernel:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
audit: type=1400 audit(1625477182.880:10): avc: denied { read } for pid=1 comm="init" name="init" dev="mmcblk0p2" ino=156 scontext=u:r:kernel:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=0
init: #00 pc 00048b13 /system/bin/init
init: #01 pc 00068dcf /system/bin/init
init: #02 pc 0000857d /system/lib/libbase.so
init: #03 pc 0004b1fd /system/bin/init
init: #04 pc 00059213 /system/lib/bootstrap/libc.so
SeLinux is used to enhance the security of the Linux system. In the article talking about the trusted execution environment , I mentioned that sometimes it is too secure and will cause inconvenience to users. Just like some systems force users to set complex passwords, but complex passwords are not easy to remember. The same is true of SeLinux, which is very safe, but very complicated. A little mistake in the rules can cause the program to fail to execute. I've had so many troubles with SeLinux in my past products that I ended up shutting it down.
With this idea, I also plan to set the SeLinux mode to Permissive (only print the log, but do not limit permissions). I have found a lot of information on the Internet, and I have also sought help from the developers of the Hongmeng system, but I still can't solve the problem. Of course, this is also the reason for my lack of skill. I did system development before, but it did not involve the kernel, which is like a mountain, and needs further study and research.
During this period of time, I have been immersed in the open source Hongmeng system. The so-called love and responsibility are deep. I can't help but complain about the open source Hongmeng system.
The first is the documentation issue . Most open source systems suffer from insufficient documentation, and many developers envelope source code as the best documentation. But the problem with the open source Hongmeng system is not the lack of documentation, but the confusion, such as:
There are three documents in the Ubuntu compilation environment preparation, and the content is also different. Which document should be read. Even if some documents are suitable for standard systems and some are suitable for Lite OS, it should be clearly written. It is better to get a few documents in this way than to have no documents.
Secondly, AOSP's precompiled libraries and programs are used in the open source Hongmeng system . It is no problem for the open source Hongmeng system to use the source code of AOSP, but it seems a little unreasonable that the basic system like this uses AOSP. And it didn't specify which version of AOSP to use, just put binary files in the source code system, which is very unfriendly to third-party porting. The init execution problem I encountered in the front is difficult to solve, because the super program init is precompiled with AOSP. If there is a problem, I can't check the problem through the source code.
Again, I still have to complain about the build system of the open source Hongmeng system, which is mixed with GN, Make, JSON, Python scripts, Bash scripts, etc. This is forcing programmers to have eighteen martial arts in order to understand them all. To make things even more painful, some build files were generated by scripts, which created another obstacle to tracking down the problem.
Finally, the open source Hongmeng system does not provide a standard reference platform, but uses HiSilicon's 3516DV3000 as a reference product. It is painful to study the kernel patch and kernel config of the 3516. It is difficult to distinguish which patches are for the specific hardware of the 3516 and which are the patches for the Hongmeng system. The patch also introduces symbolic links to link to the driver of the open source Hongmeng system. Unlike AOSP, the kernel and the system can be compiled separately. Maybe if you cooperate with Huawei, these will not be a problem. But for ordinary developers or small companies, it is too difficult to try the Hongmeng system.
I saw the news a few days ago that the Honor series has also begun to receive pushes from the Hongmeng system. The number of users connected to the Hongmeng system has exceeded 30 million, which is indeed a remarkable achievement. Maybe all of Huawei's strength is now devoted to the adaptation of existing products, and it is too late to consider open source projects. But for the operating system, the ecology is undoubtedly more important, and the ecology depends on the entry of more players. Huawei alone cannot build the entire operating system ecology. I hope Huawei can invest more in open source projects and transplant the Hongmeng system to more products.
Next, I will continue the transplantation of the open source Hongmeng system, so stay tuned!