[Feature Request] Alternative implementation of denylist by maintain two copies of zygote

[ccaapton]

Is your feature request related to a problem?/你的请求是否与某个问题相关？

Currently all(open-sourced) zygisk implementations hooks into a single zygote process, and need a lot of unmap/unmount/etc cleanup in case the target is in denylist.

Describe the solution you'd like/描述你想要的解决方案

In order to start a new process, system_server will connect to zygote via socket Zygote.PRIMARY_SOCKET_NAME and send all the parameters.

We can hook the system_server, intercept this connection and redirect to a daemon process. If the target app is inside denylist, we redirect the request to an untainted zygote which still listens on Zygote.PRIMARY_SOCKET_NAME, otherwise we redirect the request to zygisk process which listens on alternative socket.

In summary, we need these things:

1. hook(or ptrace) socket connect/send for system_server, change target from PRIMARY_SOCKET_NAME to a daemon socket
2. a daemon to receive messages from system_server, and redirect base on whether the app is in denylist/whitelist.
3. fork exec to get an untaint zygote which still listens on PRIMARY_SOCKET_NAME
4. injected zygote listen on custom sockets.

Additional context/其他信息

This link has a good picture portraying the app start process,

Step 1 and 2 could be merged in system_server if we can get denylist inside system_server.

[JingMatrix]

What could be the possible benefits compared to current implementation?

[ccaapton]

1. Since the process is forked from untainted zygote, it should be more future proof.
2. Potentially getting rid of ptrace to improve app startup performance.

[JingMatrix]

Both points are invalid.

1. Keep different Zygote forks is obviously more costing than only keeping mount namespace file descriptors.
2. No ptrace running for each applications.

I suggest you to study generated logs to see what are actually happening to correct your ideas on what happens.

[ccaapton]

Both points are invalid.

1. Keep different Zygote forks is obviously more costing than only keeping mount namespace file descriptors.

zygote64 RESIDENT memory is about 137M, PSS is about 7M. If two copies of zygote is too much resource, what about grapheneos guys.

2. No ptrace running for each applications.
   I suggest you to study generated logs to see what are actually happening to correct your ideas on what happens.

I never said ptrace happens on each individual app. I know that only zygote itself got traced, and the trace will stop after fork, but ptrace still causes wired hangs when zygote forks too frequently.

[JingMatrix]

My first point was made compared to the current implementaion, which only keeps mount namespace file descriptors in the daemon. And by the way, there aren't so-called a lot of unmap/unmount/etc as you conjectured.

For the second point, it seems irrelevant to DenyList implementations. If you can justify it as a valid issue, please open a new issue of it, I will be gald to improve it.

[qwerzxcva]

我提出的第一点是与当前实现进行比较，当前实现仅在守护进程中保留挂载命名空间文件描述符。顺便说一句，并没有你猜想的很多 unmap/unmount/etc。

对于第二点，它似乎与 DenyList 实现无关。如果你能证明它是一个有效的问题，请打开它的新问题，我将努力改进它。

[[APatch/KSU only] For applications without root privilege and not on the DenyList, only modules mount points are present in their mount namespaces. As an example, this is the ideal configuration for applying font customization modules to their target applications. Note: this is not implemented for Magisk, which needs root mounting points to receive root permission requests]
Does this work for the magic count mode of kernelsu next? kernelsu next is not overlayfs (although you can switch this mode )

[JingMatrix]

@qwerzxcva Yes, what is said in the README applies to all KernelSU variants.