topjohnwu 49f259065d Introduce new sepolicy injection mechanism ... In the current implementation, Magisk will either have to recreate all early mount implementation (for legacy SAR and rootfs devices) or delegate early mount to first stage init (for 2SI devices) to access required partitions for loading sepolicy. It then has to recreate the split sepolicy loading implementation in-house, apply patches, then dump the compiled + patched policies into monolithic format somewhere. Finally, it patches the original init to force it to load the sepolicy file we just created. With the increasing complexity involved in early mount and split sepolicy (there is even APEX module involved in the future!), it is about time to rethink Magisk's sepolicy strategy as rebuilding init's functionality is not scalable and easy to maintain. In this commit, instead of building sepolicy ourselves, we mock selinuxfs with FIFO files connected to a pre-init daemon, waiting for the actual init process to directly write the sepolicy file into MagiskInit. We then patch the file and load it into the kernel. Some FIFO tricks has to be used to hijack the original init process's control flow and prevent race conditions, details are directly in the comments in code. At the moment, only system-as-root (read-only root) support is added. Support for legacy rootfs devices will come with a follow up commit.		2022-03-16 00:31:55 -07:00
..
compat.cpp	Introduce new sepolicy injection mechanism	2022-03-16 00:31:55 -07:00
fortify.hpp	Separate libc.a hacks into its own component	2022-01-31 02:09:08 -08:00