2020-06-17 08:17:28 +00:00
|
|
|
#include <utils.hpp>
|
2019-12-13 11:05:12 +00:00
|
|
|
|
2021-10-26 07:35:55 +00:00
|
|
|
using kv_pairs = std::vector<std::pair<std::string, std::string>>;
|
|
|
|
|
2022-01-20 04:28:01 +00: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 04:31:22 +00:00
|
|
|
#define ENABLE_AVD_HACK 0
|
2022-01-20 04:28:01 +00:00
|
|
|
|
2021-10-26 07:35:55 +00:00
|
|
|
struct BootConfig {
|
2020-12-31 06:11:24 +00:00
|
|
|
bool skip_initramfs;
|
|
|
|
bool force_normal_boot;
|
|
|
|
bool rootwait;
|
2022-01-19 13:12:11 +00:00
|
|
|
bool emulator;
|
2020-12-31 06:11:24 +00:00
|
|
|
char slot[3];
|
|
|
|
char dt_dir[64];
|
|
|
|
char fstab_suffix[32];
|
|
|
|
char hardware[32];
|
|
|
|
char hardware_plat[32];
|
2021-10-26 07:35:55 +00:00
|
|
|
|
|
|
|
void set(const kv_pairs &);
|
|
|
|
void print();
|
2019-05-27 07:29:43 +00:00
|
|
|
};
|
|
|
|
|
2020-05-04 05:49:54 +00:00
|
|
|
#define DEFAULT_DT_DIR "/proc/device-tree/firmware/android"
|
|
|
|
|
2021-01-15 05:14:54 +00:00
|
|
|
extern std::vector<std::string> mount_list;
|
|
|
|
|
2022-03-17 03:01:26 +00:00
|
|
|
int magisk_proxy_main(int argc, char *argv[]);
|
2021-01-18 12:25:26 +00:00
|
|
|
bool unxz(int fd, const uint8_t *buf, size_t size);
|
2021-10-26 07:35:55 +00:00
|
|
|
void load_kernel_info(BootConfig *config);
|
2020-09-03 04:20:00 +00:00
|
|
|
bool check_two_stage();
|
2020-05-04 05:49:54 +00:00
|
|
|
void setup_klog();
|
2021-10-31 01:59:20 +00:00
|
|
|
const char *backup_init();
|
2020-05-04 05:49:54 +00:00
|
|
|
|
2020-04-19 11:56:56 +00: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 07:47:29 +00:00
|
|
|
* Base classes
|
2020-04-19 11:56:56 +00: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 07:47:29 +00:00
|
|
|
|
2019-06-16 19:45:32 +00:00
|
|
|
class BaseInit {
|
|
|
|
protected:
|
2021-10-26 07:35:55 +00:00
|
|
|
BootConfig *config = nullptr;
|
2021-08-14 05:29:12 +00: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 07:47:29 +00:00
|
|
|
|
2020-12-31 06:11:24 +00:00
|
|
|
[[noreturn]] void exec_init();
|
2019-06-22 10:14:33 +00:00
|
|
|
public:
|
2022-03-14 11:22:09 +00:00
|
|
|
BaseInit(char *argv[], BootConfig *config = nullptr) : config(config), argv(argv) {}
|
2020-12-31 06:11:24 +00:00
|
|
|
virtual ~BaseInit() = default;
|
|
|
|
virtual void start() = 0;
|
2019-06-22 10:14:33 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
class MagiskInit : public BaseInit {
|
2022-03-17 04:31:22 +00:00
|
|
|
private:
|
|
|
|
void mount_rules_dir();
|
2019-06-22 10:14:33 +00:00
|
|
|
protected:
|
2021-01-13 06:50:55 +00:00
|
|
|
mmap_data self;
|
2022-03-14 11:22:09 +00:00
|
|
|
mmap_data magisk_cfg;
|
2020-12-31 06:11:24 +00:00
|
|
|
std::string custom_rules_dir;
|
|
|
|
|
2022-01-20 04:28:01 +00:00
|
|
|
#if ENABLE_AVD_HACK
|
2022-01-19 13:12:11 +00: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 04:28:01 +00:00
|
|
|
#endif
|
2022-01-19 13:12:11 +00:00
|
|
|
|
2022-03-17 03:01:26 +00:00
|
|
|
void patch_sepolicy(const char *file);
|
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 07:31:53 +00:00
|
|
|
void hijack_sepolicy();
|
2020-12-31 06:11:24 +00:00
|
|
|
void setup_tmp(const char *path);
|
2022-03-14 11:22:09 +00:00
|
|
|
void patch_rw_root();
|
2019-05-27 07:29:43 +00:00
|
|
|
public:
|
2022-03-14 11:22:09 +00:00
|
|
|
using BaseInit::BaseInit;
|
2019-06-23 22:14:47 +00:00
|
|
|
};
|
|
|
|
|
2022-03-14 11:22:09 +00:00
|
|
|
class SARBase : public MagiskInit {
|
2019-06-23 22:14:47 +00:00
|
|
|
protected:
|
2020-12-31 06:11:24 +00:00
|
|
|
std::vector<raw_file> overlays;
|
2019-06-24 08:21:33 +00:00
|
|
|
|
2020-12-31 06:11:24 +00:00
|
|
|
void backup_files();
|
2022-03-14 11:22:09 +00:00
|
|
|
void patch_ro_root();
|
2019-06-23 22:14:47 +00:00
|
|
|
public:
|
2022-03-14 11:22:09 +00:00
|
|
|
using MagiskInit::MagiskInit;
|
2019-06-23 22:14:47 +00:00
|
|
|
};
|
|
|
|
|
2020-04-19 11:56:56 +00:00
|
|
|
/***************
|
2019-09-22 09:15:31 +00:00
|
|
|
* 2 Stage Init
|
2020-04-19 11:56:56 +00:00
|
|
|
***************/
|
2019-06-16 19:45:32 +00:00
|
|
|
|
2020-04-01 11:39:28 +00:00
|
|
|
class FirstStageInit : public BaseInit {
|
2019-12-12 08:25:48 +00:00
|
|
|
private:
|
2020-12-31 06:11:24 +00:00
|
|
|
void prepare();
|
2019-09-22 09:15:31 +00:00
|
|
|
public:
|
2022-03-14 11:22:09 +00:00
|
|
|
FirstStageInit(char *argv[], BootConfig *config) : BaseInit(argv, config) {
|
2020-12-31 06:11:24 +00:00
|
|
|
LOGD("%s\n", __FUNCTION__);
|
|
|
|
};
|
|
|
|
void start() override {
|
|
|
|
prepare();
|
|
|
|
exec_init();
|
|
|
|
}
|
2019-09-22 09:15:31 +00:00
|
|
|
};
|
|
|
|
|
2022-03-14 11:22:09 +00: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 11:56:56 +00:00
|
|
|
/*************
|
2019-09-22 09:15:31 +00:00
|
|
|
* Legacy SAR
|
2020-04-19 11:56:56 +00: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 07:47:29 +00:00
|
|
|
|
2022-03-14 11:22:09 +00:00
|
|
|
class LegacySARInit : public SARBase {
|
2020-10-27 03:46:15 +00:00
|
|
|
private:
|
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 07:31:53 +00:00
|
|
|
bool mount_system_root();
|
2020-12-31 06:11:24 +00:00
|
|
|
void first_stage_prep();
|
2020-10-27 03:46:15 +00:00
|
|
|
public:
|
2022-03-14 11:22:09 +00:00
|
|
|
LegacySARInit(char *argv[], BootConfig *config) : SARBase(argv, config) {
|
2020-12-31 06:11:24 +00:00
|
|
|
LOGD("%s\n", __FUNCTION__);
|
|
|
|
};
|
|
|
|
void start() override {
|
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 07:31:53 +00:00
|
|
|
if (mount_system_root())
|
2020-12-31 06:11:24 +00:00
|
|
|
first_stage_prep();
|
|
|
|
else
|
2022-03-14 11:22:09 +00:00
|
|
|
patch_ro_root();
|
2020-12-31 06:11:24 +00:00
|
|
|
exec_init();
|
|
|
|
}
|
2020-10-27 03:46:15 +00:00
|
|
|
};
|
|
|
|
|
2020-04-19 11:56:56 +00: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 07:47:29 +00:00
|
|
|
* Initramfs
|
2020-04-19 11:56:56 +00: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 07:47:29 +00:00
|
|
|
|
2022-03-14 11:22:09 +00:00
|
|
|
class RootFSInit : public MagiskInit {
|
2019-12-12 08:25:48 +00:00
|
|
|
private:
|
2022-03-17 03:01:26 +00:00
|
|
|
void prepare();
|
2019-06-16 19:45:32 +00:00
|
|
|
public:
|
2022-03-14 11:22:09 +00:00
|
|
|
RootFSInit(char *argv[], BootConfig *config) : MagiskInit(argv, config) {
|
2020-12-31 06:11:24 +00:00
|
|
|
LOGD("%s\n", __FUNCTION__);
|
|
|
|
}
|
|
|
|
void start() override {
|
2022-03-17 03:01:26 +00:00
|
|
|
prepare();
|
2022-03-14 11:22:09 +00:00
|
|
|
patch_rw_root();
|
2021-08-14 05:29:12 +00:00
|
|
|
exec_init();
|
|
|
|
}
|
|
|
|
};
|