Hook improvements (take 2)

[arter97]

Hi @tiann.

Thanks for the great project, I had great fun playing around with it.

This PR mainly tries to further minimize the possible delays caused by KernelSU hooking.

There are 3 major changes:

• Processes with 0 < UID < 2000 are blocked straight-up before going through the allow_list.
  I don't see any need for such processes to be interested in root, and this allows returning early before going through a more expensive lookup.
  If there's an expected breakage due to this change, I'll remove it. Let me know.
• A page-sized (4K) bitmap is added.
  This allows O(1) lookup for UID <= 32767.
  This speeds up ksu_is_allow_uid() by about 4.8x by sacrificing a 4K memory. IMHO, a good trade-off.
  Most notably, this reduces the 99.999% result previously from worrying milliseconds scale to microseconds scale.
  For UID > 32767, another page-sized (4K) sequential array is used to cache allow_list.

Compared to the previous PR #557, this new approach gives another nice 25% performance boost in average, 63-96% boost in worst cases.

Benchmark results are available at https://docs.google.com/spreadsheets/d/1w_tO1zRLPNMFRer49pL1TQfL6ndEhilRrDU1XFIcWXY/edit?usp=sharing

Thanks!

[tiann]

Is the struct list_head allow_list still useful? I noticed that it is not used at all in __ksu_is_allow_uid. We are concerned about this structure because the upcoming App Profile feature may store more information in struct perm_data, not just a bool and uid.

[arter97]

Is the struct list_head allow_list still useful? I noticed that it is not used at all in __ksu_is_allow_uid.

Not really, but I left it that way to avoid changing other code like saving it in /data/adb.

We are concerned about this structure because the upcoming App Profile feature may store more information in struct perm_data, not just a bool and uid.

Right now, the bitmap and the array introduced in this commit is enough to replace the linked-list in ksu_is_allow_uid(), but we can re-introduce (partially revert) it if it needs more complex data structure in the future. The key point of this PR is to avoid as much overhead as possible for non-target processes, not necessarily replacing the entire linked-list.

So for example, if we decided to add more members to the linked-list structure, we can leave the new PR code intact and just use it to determine whether to check the linked-list or not. This will incur a small overhead in superuser apps, but leave the non-target processes' overhead to minimal.

[tiann]

Sorry for the late reply!

These days I am developing the "App Profile" feature, which requires storing more information inside the perm_data structure and enabling each root process to access this information. This may potentially compromise the current optimization, and I am striving to stabilize this behavior as much as possible. Rest assured that I will update you here once this feature is completed.

[tiann]

Hi, @arter97 "App Profile" has been released for some time now and the feedback has been good; I believe the core data structure will remain stable for some time, and if you wish, you are welcome to port your changes to the new version!

[arter97]

Good to hear.

I'll look over the changes and update the PR soon.

Thanks!

[arter97]

Hi @tiann, the new app profile feature doesn't seem to conflict much with the changes I've made.

I've updated the PR to cleanly merge on the latest main. I don't expect any behavior differences.

Thanks.

[tiann]

Thank you, it works great!