Value of <dt>/fstab/<partition>/dev and <dt>/fstab/<partition>/type in official Android emulator ends with newline instead of \0, Magisk wonβt be able to patch sepolicy and crash the system.
Signed-off-by: Shaka Huang <shakalaca@gmail.com>
The existing method for handling legacy SAR is:
1. Mount /sbin tmpfs overlay
2. Dump all patched/new files into /sbin
3. Magic mount root dir and re-exec patched stock init
With Android 11 removing the /sbin folder, it is quite obvious that
things completely break down right in step 1.
To overcome this issue, we have to find a way to swap out the init
binary AFTER we re-exec stock init. This is where 2SI comes to rescue!
2SI normal boot procedure is:
1st stage -> Load sepolicy -> 2nd stage -> boot continue...
2SI Magisk boot procedure is:
MagiskInit 1st stage -> Stock 1st stage -> MagiskInit 2nd Stage ->
-> Stock init load sepolicy -> Stock 2nd stage -> boot continue...
As you can see, the trick is to make stock 1st stage init re-exec back
into MagiskInit so we can do our setup. This is possible by manipulating
some ramdisk files on initramfs based 2SI devices (old ass non SAR
devices AND super modern devices like Pixel 3/4), but not possible
on device that are stuck using legacy SAR (device that are not that
modern but not too old, like Pixel 1/2. Fucking Google logic!!)
This commit introduces a new way to intercept stock init re-exec flow:
ptrace init with forked tracer, monitor PTRACE_EVENT_EXEC, then swap
out the init file with bind mounts right before execv returns!
Going through this flow however will lose some necessary backup files,
so some bookkeeping has to be done by making the tracer hold these
files in memory and act as a daemon. 2nd stage MagiskInit will ack the
daemon to release these files at the correct time.
It just worksβ’ Β―\_(γ)_/Β―
readlinkat() may return random value instead of the number of bytes placed in buf and crashing the system in two ways:
1. segmentation fault (buf[-7633350] = β\0β)
2. wrong link of watchdogd, resulting dog timeout
Confirmed working in ZenFone 2 x86 series, may fix#2247 and #2356
Signed-off-by: Shaka Huang <shakalaca@gmail.com>
