10 Commits

Author SHA1 Message Date
topjohnwu
1e2f776b83 Move logging.hpp 2020-06-17 01:17:28 -07:00
topjohnwu
dbf8c41209 Force init to load fstab from file in 2SI
Patching DTBs is proven to be difficult and problematic as there are
tons of different formats out there. Adding support for all the formats
in magiskboot has been quite an headache in the past year, and it still
definitely does not cover all possible cases of them out there.

There is another issue: fake dt fstabs. Some super old devices do not
have device trees in their boot images, so some custom ROM developers
had came up with a "genius" solution: hardcode fstab entries directly
in the kernel source code and create fake device tree nodes even if
Android 10+ init can graciously take fstab files instead (-_-) 。。。

And there is YET another issue: DTBs are not always in boot images!
Google is crazy enough to litter DTBs all over the place, it is like
they cannot make up their minds (duh). This means the dt fstabs can be
either concatnated after the kernel (1), in the DTB partition (2), in
the DTBO partition (3), in the recovery_dtbo section in boot images (4),
or in the dtb section in boot images (5). FIVE f**king places, how can
anyone keep up with that!

With Android 10+ that uses 2 stage inits, it is crutual for Magisk to
be able to modify fstab mount points in order to let the original init
mount partitions for us, but NOT switch root and continue booting. For
devices using dt for early mount fstab, we used to patch the DTB at
install time with magiskboot. However these changes are permanent and
cannot be restored back at reinstallation.

With this commit, Magisk will read dt fstabs and write them to ramdisk
at boot time. And in that case, the init binary will also be patched
to force it to NEVER use fstabs in device-tree. By doing so, we can
unify ramdisk based 2SI fstab patching as basically we are just patching
fstab files. This also means we can manipulate fstab whatever Magisk
needs in the future without the need to going through the headache that
is patching DTBs at installation.
2020-05-04 02:21:51 -07:00
topjohnwu
0c99c4d93f More complete support for fstab in dt 2020-05-03 22:49:54 -07:00
topjohnwu
e219867cdf Hijack another binary for 2nd stage
Instead of using ptrace hacks, use another hack instead :D
2020-04-19 22:15:12 -07:00
topjohnwu
765d5d9729 Small magiskinit cleanup 2020-04-19 04:57:18 -07:00
topjohnwu
d959c35723 Make cleaner mount info 2020-04-18 18:50:25 -07:00
topjohnwu
e0a281583d Preparation for dynamic tmpfs path 2020-04-12 05:34:56 -07:00
topjohnwu
5f1174de27 Introduce new boot flow to handle SAR 2SI
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™  ¯\_(ツ)_/¯
2020-04-01 04:39:28 -07:00
topjohnwu
543ce937ec Don't need to find system_dev 2020-03-31 22:41:25 -07:00
topjohnwu
a0998009c1 Small native code reorganization 2020-03-09 01:50:30 -07:00