Magisk/native/src/init/init.hpp

159 lines
3.4 KiB
C++
Raw Normal View History

2022-05-12 11:03:42 +02:00
#include <base.hpp>
2022-07-06 06:13:09 +02:00
#include <init-rs.hpp>
2021-10-26 09:35:55 +02:00
using kv_pairs = std::vector<std::pair<std::string, std::string>>;
2022-01-20 05:28:01 +01:00
// For API 28 AVD, it uses legacy SAR setup that requires
// special hacks in magiskinit to work properly. We do not
// necessarily want this enabled in production builds.
2022-03-17 05:31:22 +01:00
#define ENABLE_AVD_HACK 0
2022-01-20 05:28:01 +01:00
2021-10-26 09:35:55 +02:00
struct BootConfig {
bool skip_initramfs;
bool force_normal_boot;
bool rootwait;
2022-01-19 14:12:11 +01:00
bool emulator;
char slot[3];
char dt_dir[64];
char fstab_suffix[32];
char hardware[32];
char hardware_plat[32];
2021-10-26 09:35:55 +02:00
void set(const kv_pairs &);
void print();
2019-05-27 09:29:43 +02:00
};
2020-05-04 07:49:54 +02:00
#define DEFAULT_DT_DIR "/proc/device-tree/firmware/android"
#define INIT_PATH "/system/bin/init"
#define REDIR_PATH "/data/magiskinit"
2020-05-04 07:49:54 +02:00
2021-01-15 06:14:54 +01:00
extern std::vector<std::string> mount_list;
int magisk_proxy_main(int argc, char *argv[]);
2021-01-18 13:25:26 +01:00
bool unxz(int fd, const uint8_t *buf, size_t size);
2021-10-26 09:35:55 +02:00
void load_kernel_info(BootConfig *config);
2020-09-03 06:20:00 +02:00
bool check_two_stage();
2020-05-04 07:49:54 +02:00
void setup_klog();
const char *backup_init();
void restore_ramdisk_init();
int dump_preload(const char *path, mode_t mode);
2020-05-04 07:49:54 +02:00
2020-04-19 13:56:56 +02:00
/***************
Logical Resizable Android Partitions support The way how logical partition, or "Logical Resizable Android Partitions" as they say in AOSP source code, is setup makes it impossible to early mount the partitions from the shared super partition with just a few lines of code; in fact, AOSP has a whole "fs_mgr" folder which consist of multiple complex libraries, with 15K lines of code just to deal with the device mapper shenanigans. In order to keep the already overly complicated MagiskInit more managable, I chose NOT to go the route of including fs_mgr directly into MagiskInit. Luckily, starting from Android Q, Google decided to split init startup into 3 stages, with the first stage doing _only_ early mount. This is great news, because we can simply let the stock init do its own thing for us, and we intercept the bootup sequence. So the workflow can be visualized roughly below: Magisk First Stage --> First Stage Mount --> Magisk Second Stage --+ (MagiskInit) (Original Init) (MagiskInit) + + + ...Rest of the boot... <-- Second Stage <-- Selinux Setup <--+ (__________________ Original Init ____________________) The catch here is that after doing all the first stage mounting, /init will pivot /system as root directory (/), leaving us impossible to regain control after we hand it over. So the solution here is to patch fstab in /first_stage_ramdisk on-the-fly to redirect /system to /system_root, making the original init do all the hard work for us and mount required early mount partitions, but skips the step of switching root directory. It will also conveniently hand over execution back to MagiskInit, which we will reuse the routine for patching root directory in normal system-as-root situations.
2019-06-29 09:47:29 +02:00
* Base classes
2020-04-19 13:56:56 +02:00
***************/
Logical Resizable Android Partitions support The way how logical partition, or "Logical Resizable Android Partitions" as they say in AOSP source code, is setup makes it impossible to early mount the partitions from the shared super partition with just a few lines of code; in fact, AOSP has a whole "fs_mgr" folder which consist of multiple complex libraries, with 15K lines of code just to deal with the device mapper shenanigans. In order to keep the already overly complicated MagiskInit more managable, I chose NOT to go the route of including fs_mgr directly into MagiskInit. Luckily, starting from Android Q, Google decided to split init startup into 3 stages, with the first stage doing _only_ early mount. This is great news, because we can simply let the stock init do its own thing for us, and we intercept the bootup sequence. So the workflow can be visualized roughly below: Magisk First Stage --> First Stage Mount --> Magisk Second Stage --+ (MagiskInit) (Original Init) (MagiskInit) + + + ...Rest of the boot... <-- Second Stage <-- Selinux Setup <--+ (__________________ Original Init ____________________) The catch here is that after doing all the first stage mounting, /init will pivot /system as root directory (/), leaving us impossible to regain control after we hand it over. So the solution here is to patch fstab in /first_stage_ramdisk on-the-fly to redirect /system to /system_root, making the original init do all the hard work for us and mount required early mount partitions, but skips the step of switching root directory. It will also conveniently hand over execution back to MagiskInit, which we will reuse the routine for patching root directory in normal system-as-root situations.
2019-06-29 09:47:29 +02:00
2019-06-16 21:45:32 +02:00
class BaseInit {
protected:
2021-10-26 09:35:55 +02:00
BootConfig *config = nullptr;
2021-08-14 07:29:12 +02:00
char **argv = nullptr;
Logical Resizable Android Partitions support The way how logical partition, or "Logical Resizable Android Partitions" as they say in AOSP source code, is setup makes it impossible to early mount the partitions from the shared super partition with just a few lines of code; in fact, AOSP has a whole "fs_mgr" folder which consist of multiple complex libraries, with 15K lines of code just to deal with the device mapper shenanigans. In order to keep the already overly complicated MagiskInit more managable, I chose NOT to go the route of including fs_mgr directly into MagiskInit. Luckily, starting from Android Q, Google decided to split init startup into 3 stages, with the first stage doing _only_ early mount. This is great news, because we can simply let the stock init do its own thing for us, and we intercept the bootup sequence. So the workflow can be visualized roughly below: Magisk First Stage --> First Stage Mount --> Magisk Second Stage --+ (MagiskInit) (Original Init) (MagiskInit) + + + ...Rest of the boot... <-- Second Stage <-- Selinux Setup <--+ (__________________ Original Init ____________________) The catch here is that after doing all the first stage mounting, /init will pivot /system as root directory (/), leaving us impossible to regain control after we hand it over. So the solution here is to patch fstab in /first_stage_ramdisk on-the-fly to redirect /system to /system_root, making the original init do all the hard work for us and mount required early mount partitions, but skips the step of switching root directory. It will also conveniently hand over execution back to MagiskInit, which we will reuse the routine for patching root directory in normal system-as-root situations.
2019-06-29 09:47:29 +02:00
[[noreturn]] void exec_init();
void prepare_data();
2019-06-22 12:14:33 +02:00
public:
2022-03-14 12:22:09 +01:00
BaseInit(char *argv[], BootConfig *config = nullptr) : config(config), argv(argv) {}
virtual ~BaseInit() = default;
virtual void start() = 0;
2019-06-22 12:14:33 +02:00
};
class MagiskInit : public BaseInit {
2022-03-17 05:31:22 +01:00
private:
dev_t preinit_dev = 0;
void parse_config_file();
void patch_sepolicy(const char *in, const char *out);
bool hijack_sepolicy();
void setup_tmp(const char *path);
2019-06-22 12:14:33 +02:00
protected:
2022-01-20 05:28:01 +01:00
#if ENABLE_AVD_HACK
2022-01-19 14:12:11 +01:00
// When this boolean is set, this means we are currently
// running magiskinit on legacy SAR AVD emulator
bool avd_hack = false;
2022-01-20 05:28:01 +01:00
#endif
2022-01-19 14:12:11 +01:00
2022-03-14 12:22:09 +01:00
void patch_rw_root();
void patch_ro_root();
2019-05-27 09:29:43 +02:00
public:
2022-03-14 12:22:09 +01:00
using BaseInit::BaseInit;
};
2022-03-14 12:22:09 +01:00
class SARBase : public MagiskInit {
public:
2022-03-14 12:22:09 +01:00
using MagiskInit::MagiskInit;
};
2020-04-19 13:56:56 +02:00
/***************
2019-09-22 11:15:31 +02:00
* 2 Stage Init
2020-04-19 13:56:56 +02:00
***************/
2019-06-16 21:45:32 +02:00
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 13:39:28 +02:00
class FirstStageInit : public BaseInit {
2019-12-12 09:25:48 +01:00
private:
void prepare();
2019-09-22 11:15:31 +02:00
public:
2022-03-14 12:22:09 +01:00
FirstStageInit(char *argv[], BootConfig *config) : BaseInit(argv, config) {
LOGD("%s\n", __FUNCTION__);
};
void start() override {
prepare();
exec_init();
}
2019-09-22 11:15:31 +02:00
};
2022-03-14 12:22:09 +01:00
class SecondStageInit : public SARBase {
private:
bool prepare();
public:
SecondStageInit(char *argv[]) : SARBase(argv) {
setup_klog();
LOGD("%s\n", __FUNCTION__);
};
void start() override {
if (prepare())
patch_rw_root();
else
patch_ro_root();
exec_init();
}
};
2020-04-19 13:56:56 +02:00
/*************
2019-09-22 11:15:31 +02:00
* Legacy SAR
2020-04-19 13:56:56 +02:00
*************/
Logical Resizable Android Partitions support The way how logical partition, or "Logical Resizable Android Partitions" as they say in AOSP source code, is setup makes it impossible to early mount the partitions from the shared super partition with just a few lines of code; in fact, AOSP has a whole "fs_mgr" folder which consist of multiple complex libraries, with 15K lines of code just to deal with the device mapper shenanigans. In order to keep the already overly complicated MagiskInit more managable, I chose NOT to go the route of including fs_mgr directly into MagiskInit. Luckily, starting from Android Q, Google decided to split init startup into 3 stages, with the first stage doing _only_ early mount. This is great news, because we can simply let the stock init do its own thing for us, and we intercept the bootup sequence. So the workflow can be visualized roughly below: Magisk First Stage --> First Stage Mount --> Magisk Second Stage --+ (MagiskInit) (Original Init) (MagiskInit) + + + ...Rest of the boot... <-- Second Stage <-- Selinux Setup <--+ (__________________ Original Init ____________________) The catch here is that after doing all the first stage mounting, /init will pivot /system as root directory (/), leaving us impossible to regain control after we hand it over. So the solution here is to patch fstab in /first_stage_ramdisk on-the-fly to redirect /system to /system_root, making the original init do all the hard work for us and mount required early mount partitions, but skips the step of switching root directory. It will also conveniently hand over execution back to MagiskInit, which we will reuse the routine for patching root directory in normal system-as-root situations.
2019-06-29 09:47:29 +02:00
2022-03-14 12:22:09 +01:00
class LegacySARInit : public SARBase {
2020-10-27 04:46:15 +01:00
private:
bool mount_system_root();
void first_stage_prep();
2020-10-27 04:46:15 +01:00
public:
2022-03-14 12:22:09 +01:00
LegacySARInit(char *argv[], BootConfig *config) : SARBase(argv, config) {
LOGD("%s\n", __FUNCTION__);
};
void start() override {
prepare_data();
if (mount_system_root())
first_stage_prep();
else
2022-03-14 12:22:09 +01:00
patch_ro_root();
exec_init();
}
2020-10-27 04:46:15 +01:00
};
2020-04-19 13:56:56 +02:00
/************
Logical Resizable Android Partitions support The way how logical partition, or "Logical Resizable Android Partitions" as they say in AOSP source code, is setup makes it impossible to early mount the partitions from the shared super partition with just a few lines of code; in fact, AOSP has a whole "fs_mgr" folder which consist of multiple complex libraries, with 15K lines of code just to deal with the device mapper shenanigans. In order to keep the already overly complicated MagiskInit more managable, I chose NOT to go the route of including fs_mgr directly into MagiskInit. Luckily, starting from Android Q, Google decided to split init startup into 3 stages, with the first stage doing _only_ early mount. This is great news, because we can simply let the stock init do its own thing for us, and we intercept the bootup sequence. So the workflow can be visualized roughly below: Magisk First Stage --> First Stage Mount --> Magisk Second Stage --+ (MagiskInit) (Original Init) (MagiskInit) + + + ...Rest of the boot... <-- Second Stage <-- Selinux Setup <--+ (__________________ Original Init ____________________) The catch here is that after doing all the first stage mounting, /init will pivot /system as root directory (/), leaving us impossible to regain control after we hand it over. So the solution here is to patch fstab in /first_stage_ramdisk on-the-fly to redirect /system to /system_root, making the original init do all the hard work for us and mount required early mount partitions, but skips the step of switching root directory. It will also conveniently hand over execution back to MagiskInit, which we will reuse the routine for patching root directory in normal system-as-root situations.
2019-06-29 09:47:29 +02:00
* Initramfs
2020-04-19 13:56:56 +02:00
************/
Logical Resizable Android Partitions support The way how logical partition, or "Logical Resizable Android Partitions" as they say in AOSP source code, is setup makes it impossible to early mount the partitions from the shared super partition with just a few lines of code; in fact, AOSP has a whole "fs_mgr" folder which consist of multiple complex libraries, with 15K lines of code just to deal with the device mapper shenanigans. In order to keep the already overly complicated MagiskInit more managable, I chose NOT to go the route of including fs_mgr directly into MagiskInit. Luckily, starting from Android Q, Google decided to split init startup into 3 stages, with the first stage doing _only_ early mount. This is great news, because we can simply let the stock init do its own thing for us, and we intercept the bootup sequence. So the workflow can be visualized roughly below: Magisk First Stage --> First Stage Mount --> Magisk Second Stage --+ (MagiskInit) (Original Init) (MagiskInit) + + + ...Rest of the boot... <-- Second Stage <-- Selinux Setup <--+ (__________________ Original Init ____________________) The catch here is that after doing all the first stage mounting, /init will pivot /system as root directory (/), leaving us impossible to regain control after we hand it over. So the solution here is to patch fstab in /first_stage_ramdisk on-the-fly to redirect /system to /system_root, making the original init do all the hard work for us and mount required early mount partitions, but skips the step of switching root directory. It will also conveniently hand over execution back to MagiskInit, which we will reuse the routine for patching root directory in normal system-as-root situations.
2019-06-29 09:47:29 +02:00
2022-03-14 12:22:09 +01:00
class RootFSInit : public MagiskInit {
2019-12-12 09:25:48 +01:00
private:
void prepare();
2019-06-16 21:45:32 +02:00
public:
2022-03-14 12:22:09 +01:00
RootFSInit(char *argv[], BootConfig *config) : MagiskInit(argv, config) {
LOGD("%s\n", __FUNCTION__);
}
void start() override {
prepare();
2022-03-14 12:22:09 +01:00
patch_rw_root();
2021-08-14 07:29:12 +02:00
exec_init();
}
};