Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KSU bug in granting root for apps on BlissOS #2113

Open
3 tasks done
hmtheboy154 opened this issue Oct 2, 2024 · 40 comments
Open
3 tasks done

KSU bug in granting root for apps on BlissOS #2113

hmtheboy154 opened this issue Oct 2, 2024 · 40 comments

Comments

@hmtheboy154
Copy link
Contributor

Please check before submitting an issue

  • I have searched the issues and haven't found anything relevant
  • I will upload bugreport file in KernelSU Manager - Settings - Report log
  • I know how to reproduce the issue which may not be specific to my device

Describe the bug

(This issue may look like #2095, but I can't verify yet)
Currently with latest KSU on BlissOS, tested on kernel 6.1 & 6.6 & 6.9 & 6.11, there are some bugs that I started to notice: While some apps like Aurora Store, Neo Store & FoxLog can be able to grant root and use normally, some are broken in functions or just straight up not working:

  • Termux can only be able to go to su if using /system/bin/su, and when in su no $PATH is set other than Termux or KSU own path.
  • MiXplorer can't be able to use Allow Root even set with rootexplorer.root or system template. I tried another app Amaze File Manager with their Root Explorer & Use legacy listing for root and it can do things like show the whole /data but can't access anything in /data/app.
  • If using another term app like TermOnePlus, it will not working even if using either su or /system/bin/su

All recent BlissOS builds with KernelSU 1.0.1 have this issue. And currently they are on kernel 6.1. I bumped kernel to 6.6 to test locally and it show the same behaviour. For newer kernel that are on stable branch, the same behaviour can be seen on this PR I made . Recently I do try to build for kernel 6.11 and it also have the same behaviour (here is my fork for 6.11).

To Reproduce

  • For kernel 6.1 + KSU 1.0.1 testing, download any latest stable build of BlissOS
  • For kernel 6.1 + KSU 0.9.2 testing, download older builds such as 16.9.6, 15.9.1 or 14.10.2
  • For kernel 6.9 + KSU 0.9.2 testing, download latest BlissOS Zenith (16.9.6)
  • For kernel 6.6 + KSU 1.0.1 or kernel 6.11 + KSU 1.0.1 tesing, it's currently WIP and still being worked on. If anyone ask, I'll provide.

Expected behavior

Apps can be able to grant root and work as expected

Screenshots

An example of Termux can't use su can be seen here : #1785 (comment)

Logs

will provide soon

Device info

  • Device: Generic x86_64-v2 devices
  • OS Version: Android 11/12.1/13/14
  • KernelSU Version: 1.0.1 (latest main)
  • Kernel Version: 6.1.x + 6.6.x + 6.11.x

Additional context

One last thing that I tested is to downgrade to 0.9.2 as some people suggested , it only work with kernel 6.1 & 6.6. If you port it to higher kernel like 6.9, it will have the exact same issue.

@hansalemaos
Copy link

hansalemaos commented Oct 3, 2024

Same problem here. It seems like something in the shell is "cloaking" the su call
If I pipe something to toybox, I can call su.

Maybe it is releated to:

# interesting detail of KernelSU - it doesn't actually place a su file in
# /system/bin, but hook execve(2) call in kernel to redirect it to kernel
# impl when executing /system/bin/su.

termux-play-store/termux-tools@9187cfa#diff-3de48b02d1685061aec7aeb7ee702149f1d3b8beee98158b5b35e9c94f88d6f7R9

2024-10-02 21_24_16-KSU bug in granting root for apps on BlissOS · Issue #2113 · tiann_KernelSU

@tiann
Copy link
Owner

tiann commented Oct 3, 2024

exec strace su and observe the output

@Xtr126
Copy link

Xtr126 commented Oct 3, 2024

/system/bin/strace su says faccessat(AT_FDCWD, "/system/bin/su", X_OK) = -1 ENOENT (No such file or directory)
Screenshot_20241003-095013
strace.txt

@tiann
Copy link
Owner

tiann commented Oct 3, 2024

It seems that this kprobe failed: https://github.com/tiann/KernelSU/blob/main/kernel/sucompat.c#L265
is there any dmesg log?

@Xtr126
Copy link

Xtr126 commented Oct 3, 2024

Looks like it has succeeded
dmesg:

[    0.621438] KernelSU: sucompat: execve_kp: 0
[    0.622879] KernelSU: sucompat: newfstatat_kp: 0
[    0.624354] KernelSU: sucompat: faccessat_kp: 0
[    0.626269] KernelSU: sucompat: devpts_kp: 0
[    0.626359] KernelSU: ksud: execve_kp: 0
[    0.628102] KernelSU: ksud: vfs_read_kp: 0
[    0.630275] KernelSU: ksud: input_event_kp: 0
[   19.383064] KernelSU: on_post_fs_data!
[   19.383068] KernelSU: unregister input kprobe: 1!
[   19.383072] KernelSU: devpts sid: 741
[   19.383073] KernelSU: unregister execve kprobe: 1!

dmesg.txt

@hmtheboy154
Copy link
Contributor Author

[   19.383068] KernelSU: unregister input kprobe: 1!
[   19.383072] KernelSU: devpts sid: 741
[   19.383073] KernelSU: unregister execve kprobe: 1!

this indicate it failed to unregister ?

@hmtheboy154
Copy link
Contributor Author

@tiann I just remember something: When I test #2041 , I test it in kernel 6.1.84. And it work perfectly fine from granting apps to using modules. After the PR got merged I upstream the kernel and then I have reports about KSU bugging.
So something in the upstream kernel is causing this. Which explain why stable branch affected the same even if using 0.9.2.

I am currently narrowing down to see up until which version does the bug happen, currently it's around 6.1.84 ~ 6.1.89

@hmtheboy154
Copy link
Contributor Author

6.1.85 is when it happen

@Xtr126
Copy link

Xtr126 commented Oct 5, 2024

I just thought, it could be that ksud init broke because modules also don't work, modules.img does not get mounted.

@hmtheboy154
Copy link
Contributor Author

I just thought, it could be that ksud init broke because modules also don't work, modules.img does not get mounted.

6.1.84 works perfectly fine with 1.0.1, here's an image for you to test
https://drive.google.com/file/d/1Z9Fc0v25gf19n-6ia3JUm8UBQGM_LuIa/view?usp=sharing

@Xtr126
Copy link

Xtr126 commented Oct 5, 2024

I just thought, it could be that ksud init broke because modules also don't work, modules.img does not get mounted.

6.1.84 works perfectly fine with 1.0.1, here's an image for you to test https://drive.google.com/file/d/1Z9Fc0v25gf19n-6ia3JUm8UBQGM_LuIa/view?usp=sharing

I have tested 6.1.84 and can confirm everything works there, but I meant in the builds with newer kernel, modules don't work or even get mounted.

@hmtheboy154
Copy link
Contributor Author

I just thought, it could be that ksud init broke because modules also don't work, modules.img does not get mounted.

6.1.84 works perfectly fine with 1.0.1, here's an image for you to test https://drive.google.com/file/d/1Z9Fc0v25gf19n-6ia3JUm8UBQGM_LuIa/view?usp=sharing

I have tested 6.1.84 and can confirm everything works there, but I meant in the builds with newer kernel, modules don't work or even get mounted.

try to get log, maybe there are more clue than faccessat() is broken

@Xtr126
Copy link

Xtr126 commented Oct 5, 2024

I tried even with loglevel=7 and checked in logcat but no clue yet. The dmesg doesn't differ much from that of the working version (6.1.84). But I saw that KernelSU has CONFIG_KSU_DEBUG, it could possibly help in getting more logs.

I just thought, it could be that ksud init broke because modules also don't work, modules.img does not get mounted.

6.1.84 works perfectly fine with 1.0.1, here's an image for you to test https://drive.google.com/file/d/1Z9Fc0v25gf19n-6ia3JUm8UBQGM_LuIa/view?usp=sharing

I have tested 6.1.84 and can confirm everything works there, but I meant in the builds with newer kernel, modules don't work or even get mounted.

try to get log, maybe there are more clue than faccessat() is broken

@hmtheboy154
Copy link
Contributor Author

@tiann found the commit:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=1e3ad78334a69b36e107232e337f9d693dcc9df2

Revert this and it KSU work as expected now. And I even test this on kernel 6.11.2

@hmtheboy154
Copy link
Contributor Author

so this seems affected all x86 platform not just Android-x86 based like us

@tiann
Copy link
Owner

tiann commented Oct 6, 2024

please check cat /proc/kallsyms and dump the symbols

@hmtheboy154
Copy link
Contributor Author

please check cat /proc/kallsyms and dump the symbols

when KSU broke or when it's working ?

@tiann
Copy link
Owner

tiann commented Oct 6, 2024

please check cat /proc/kallsyms and dump the symbols

when KSU broke or when it's working ?

broken, and the kernel image

@hmtheboy154
Copy link
Contributor Author

hmtheboy154 commented Oct 6, 2024

kallsyms.txt

and the kernel image

kernel.zip

@hmtheboy154
Copy link
Contributor Author

So as a workaround, I saw this patch in LKML:
https://lore.kernel.org/lkml/20240417164514.66hgypzxgqxt3ssk@desk/T/

I applied it and test on my kernel 6.11 and it's working so far
android-generic/kernel-zenith@0c2e19c

However, I still think that we should fix KSU itself.

@hmtheboy154
Copy link
Contributor Author

So as a workaround, I saw this patch in LKML: https://lore.kernel.org/lkml/20240417164514.66hgypzxgqxt3ssk@desk/T/

I applied it and test on my kernel 6.11 and it's working so far android-generic/kernel-zenith@0c2e19c

However, I still think that we should fix KSU itself.

Build this on 6.1 requires disabling BHI mitigations by setting spectre_bhi=off though

@hmtheboy154
Copy link
Contributor Author

@tiann I found this post : https://blog.hakuya.moe/post/13

@hmtheboy154
Copy link
Contributor Author

hmtheboy154 commented Oct 10, 2024

So as a workaround, I saw this patch in LKML: https://lore.kernel.org/lkml/20240417164514.66hgypzxgqxt3ssk@desk/T/

I applied it and test on my kernel 6.11 and it's working so far android-generic/kernel-zenith@0c2e19c

However, I still think that we should fix KSU itself.

Finalize the temp fix: android-generic/kernel-zenith@5648396

Because I don't want to fully revert, I put the option under a cmdline syscall_hardening=off . Until there's a new way to hook into x86_64 syscall, I guess this is what I can do.

@hansalemaos
Copy link

So as a workaround, I saw this patch in LKML: https://lore.kernel.org/lkml/20240417164514.66hgypzxgqxt3ssk@desk/T/
I applied it and test on my kernel 6.11 and it's working so far android-generic/kernel-zenith@0c2e19c
However, I still think that we should fix KSU itself.

Finalize the temp fix: android-generic/kernel-zenith@5648396

Because I don't want to fully revert, I put the option under a cmdline syscal_hardening=off . Until there's a new way to hook into x86_64 syscall, I guess this is what I can do.

Nice, any idea when the updated BlissOs will be online?

@hmtheboy154
Copy link
Contributor Author

So as a workaround, I saw this patch in LKML: https://lore.kernel.org/lkml/20240417164514.66hgypzxgqxt3ssk@desk/T/
I applied it and test on my kernel 6.11 and it's working so far android-generic/kernel-zenith@0c2e19c
However, I still think that we should fix KSU itself.

Finalize the temp fix: android-generic/kernel-zenith@5648396
Because I don't want to fully revert, I put the option under a cmdline syscal_hardening=off . Until there's a new way to hook into x86_64 syscall, I guess this is what I can do.

Nice, any idea when the updated BlissOs will be online?

updated, please check

@hansalemaos
Copy link

Thx, I will check that today!!

@hansalemaos
Copy link

2024-10-13 09_42_33-Window

Did not work :( Only with the Toybox trick I used before. I downloaded Bliss-v16.9.7-x86_64-OFFICIAL-gapps-20241011.iso

@hmtheboy154
Copy link
Contributor Author

hmtheboy154 commented Oct 13, 2024

2024-10-13 09_42_33-Window

Did not work :( Only with the Toybox trick I used before. I downloaded Bliss-v16.9.7-x86_64-OFFICIAL-gapps-20241011.iso

have you boot with syscall_hardening=off cmdline yet ?

@hansalemaos
Copy link

nope, I should have read your old post, let me try

@hansalemaos
Copy link

WORKING! THX SO MUCH!

@ZewZack
Copy link

ZewZack commented Nov 3, 2024

2024-10-13 09_42_33-Window
Did not work :( Only with the Toybox trick I used before. I downloaded Bliss-v16.9.7-x86_64-OFFICIAL-gapps-20241011.iso

have you boot with syscall_hardening=off cmdline yet ?

bro thank you sooo much u save my day <3 (⁀ ͜ʖ⁀)

@harryxmin
Copy link

I have to put syscall_hardening=off in the grub terminal or termux?

@Xtr126
Copy link

Xtr126 commented Nov 8, 2024

I have to put syscall_hardening=off in the grub terminal or termux?

In grub.

@harryxmin
Copy link

Thank you. It worked. I can grant root now. Is it possible to use a VPN app that is running in bliss OS on a proxmox host to be accessible by other proxmox containers?

@AFFAN129
Copy link

AFFAN129 commented Nov 22, 2024

2024-10-13 09_42_33-Window
Did not work :( Only with the Toybox trick I used before. I downloaded Bliss-v16.9.7-x86_64-OFFICIAL-gapps-20241011.iso

have you boot with syscall_hardening=off cmdline yet ?

bro how to fix ksu i don't understand even though i've read it,I want to fix in bliss os version 14.10.3

@harryxmin
Copy link

harryxmin commented Nov 23, 2024 via email

@AFFAN129
Copy link

AFFAN129 commented Nov 23, 2024 via email

@AFFAN129
Copy link

AFFAN129 commented Nov 23, 2024 via email

@AFFAN129
Copy link

So as a workaround, I saw this patch in LKML:
https://lore.kernel.org/lkml/20240417164514.66hgypzxgqxt3ssk@desk/T/

I applied it and test on my kernel 6.11 and it's working so far
android-generic/kernel-zenith@0c2e19c

However, I still think that we should fix KSU itself.

I have tried cmd but it is like this
IMG_20241123_114635_473.jpg

@olekor
Copy link

olekor commented Nov 30, 2024

Yesterday, I added syscall_hardening=off and, using Termux su managed to activate Bluetooth. However, Termux displayed a notification stating: "/system/bin/sh: hciconfig: inaccessible or not found." Despite that, Bluetooth started working. Unfortunately, this activation only lasts until I restart Bliss. After each reboot, I need to re-enter the chain of commands for hciconfig. I experimented with several reboots and was satisfied with the results, though not completely. It was an improvement over before. However, today this method is no longer working; when I enter the hciconfig commands, Bluetooth does not start. Any idea?
Currently, BT appears to be operational, but it is not as stable as it should be.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants