Magisk: [AONLY_SAR] Magisk fails to boot on Samsung Q devices with Full Permissive Kernels

Created on 7 Feb 2020  路  25Comments  路  Source: topjohnwu/Magisk

Hey, @topjohnwu

I dont know how to exactly start this issue but here is the case we have.

Basic rundown

We are unable to boot magisk on Exynos Samsung devices with Android Q (One UI 2) While having the kernel in Full permissive mode (I.E enforcing Permissive and not just removing force_enforce that Samsung implements) Which is by adding new_value = 0; which can be seen in this kernel or here for example

Affected devices

Me and my colleagues Have the issue on a variety of devices. including officially Q updated devices such as

  • Galaxy S9 +(G965F)
  • Galaxy Note 9 (N960F)
  • Galaxy S10 (G975F)
  • Galaxy Note 10 (N970F)

We have the same exact issue on devices with "Ported" Android Q oneUI 2 such as

  • Galaxy Note 8 (N950F)
  • Galaxy S8/S8+ (G950F/G955F)
  • Galaxy A5 2017 (A520F)
  • Galaxy S7 Edge (G935F)
  • Galaxy Note 5 (N920C)

Those are the devices we have currently that can confirm having this issue. i didn't want to open this issue earlier as we thought this is due to the "ported" nature of the devices on hand, however the issue was confirmed by @morogoku , @corsicanu and @renoxtv to occur on the S9 running the official Q ROM
~The issue can also be observed on the Galaxy S10 With the Permissive kernel on its own official Q ROM. however i am not going to include this in the report since i only had one person test it. and i dont have anyone else to confirm~
@ivanmeler just confirmed that the issue exists on the Official oneui Q release on the Galaxy S10 and the Note 10

How to cause it

Here are the relevant commits done in the kernel to cause this issue :

First we remove samsung always enforce. The kernel STILL boots with magisk
Remove AlwaysEnforce

Then we actually set permissive, which then the kernel fails to boot on magisk
Set permissive

Logs

Sadly logging is REALLY limited. the only logs we are able to pull are last_kmsgs. the device fails to pass spalsh, doesn't start adbd or anything that would assist in pulling logs. there are no generated tombstones. so the only logs i am able to provide are kmsgs

S7 Edge Running Oneui Q (Unofficial port) kmsg from my self : https://del.dog/herolte_oneuiQ
S9+ Running Oneui Q (Official Release) kmsg from @renoxtv: https://del.dog/star2lte_oneuiQ

Please do let me know if more logging is needed / How i can provide more information on this subject

It was hard to track it down, but basically whenever we really set permissive, magisk fails to boot. we have tried countless permissive commits. None work. aslong as the kernel is permissive, there is no current way to boot with magisk. if the kernel has always enforce removed, magisk is able to boot.

However that is not really suitable as this still boots the device in "enforcing" mode and follows all AVC denials, which might not be a problem on official devices, but makes unofficially ported devices fail to work properly.

More information if needed

It is VERY important to emphasis that we have this issue ONLY , and i mean ONLY with the Samsung Oneui 2.0 Q ROMs. The issue DOES NOT EXIST on the Same kernel + Same permissive commit + Magisk on AOSP ROMs / LineageOS (Tested on the Note 8 / S7 Edge Lineage 17 roms)

We have tried tons of combinations But nothing makes magisk run with true permissive on samsung Q roms. so unless we patch all avc denials on ported ROMs. or only use enforcing on official ROMs. we cant get magisk another way. If its important, the unofficial devices are running an almost carbon copy version of the S9 Q (both vendor and system) minus the changes needed to make the actual port.

Thank you if you are still reading and i really do hope you look into this problem

Most helpful comment

You can just use magiskpolicy to manage anything related to selinux, don't need to use sepolicy injector.

I'll close this issue now, this is not technically an issue with Magisk

And yet it is an issue with Magisk since the only way to boot rooted is with enforced selinux. But don't mind it, i heard you are busy redesigning the app instead of fixing real issues.
Just my 2 cents, take it or leave it, i won't care anyway.

All 25 comments

I am guessing you tried to patch the modified kernel with magisk and that did not work either.

I am guessing you tried to patch the modified kernel with magisk and that did not work either.

Correct, patching via the app or TWRP results in the same crash

You tried the patch boot image then flashing the patched image outside of the app? Like in ODIN or whatever Sammy users are using now. Like, chose boot.img and patch, save to pc, then flash that boot.img

You tried the patch boot image then flashing the patched image outside of the app? Like in ODIN or whatever Sammy users are using now. Like, chose boot.img and patch, save to pc, then flash that boot.img

Yep, selected the kernel in the magisk app > let it do its thing, then flashed that boot.img in TWRP under boot partition. (if i were to do this under PC its like dd via adb shell)

OK, sorry I cannot really help, just trying to clarify.

OK, sorry I cannot really help, just trying to clarify.

No problem, i am open to any ideas, as ive been tracking this issue for the past month or so. thanks regardless

@ananjaser1211 from your own logs, MagiskInit isn't even started, are you sure you have installed Magisk properly? MagiskInit is supposed to run before first stage init (line 2801 in your logs).

The log from the S9+ provides no relevant info as I need logs before and at the time init is running.

@ananjaser1211 from your own logs, MagiskInit isn't even started, are you sure you have installed Magisk properly? MagiskInit is supposed to run before first stage init (line 2801 in your logs).

The log from the S9+ provides no relevant info as I need logs before and at the time init is running.

Thanks for the response.

On my own device i have tried installing magisk in 2 ways. directly flashing the zip via TWRP and patching the boot.img via magisk manager. I have installed the latest canary build : 20.4-ed58cf95

Both result in the same scenario.

S7 Q KMSG : https://del.dog/herolte_oneuiQ_2

Ill try and get my S9 friend to send a fresh kmsg as well tmw

I really do not see much difference* from the previous, more or less the same stuff
Mainly this part

<14>[ 3.511348] [6: init: 1] init: [libfs_mgr]dt_fstab: Using a specified mount point /system_root for system

<14>[ 3.511627] [6: init: 1] init: [libfs_mgr]ReadDefaultFstab(): failed to find device default fstab

Some extra info

Does the location of the fstab matter ?

The S9 Q has 3? fstabs.
vendor/etc/fstab.samsungexynos9810 which has This
boot.img/ramdisk/fstab.samsungexynos9810 which has the exact same contents as above
device-tree/dts fstab which has this

you probably already know about these, i find it odd that the boot.img has an fstab since its supposed to be SAR.

Anyhow. i just read your twitter post about fake-fstab

my device does use that fake-fstab style to mount system

if its indeed the "fake-fstab" causing magisk to fail. how would this be resolved on official devices which suffer the same issue but use that mounting technique out of the box? Im gonna work on cleaning up my fstabs based on your twitter post, i am sure i can get rid of it and rely on the ramdisk fstab. ill update you on how that goes sometime tmw, as its 4AM now. Thanks for your time.

@ananjaser1211 I would need dmesg logs from those devices to know.
My guess would be Samsung's init might be doing something weird when kernel is set to permissive, and Magisk can't run properly

@ananjaser1211 I would need dmesg logs from those devices to know.
My guess would be Samsung's init might be doing something weird when kernel is set to permissive, and Magisk can't run properly

Do you have any way of grabbing dmesg ? there is no ADB (The device is not being picked up on both windows and linux while on splash)

edit : and yes it has to be something in the samsung init. as the issue is totally gone on AOSP using the same kernel (and SAR setup if that matters)

Edit 2: nvm I鈥檒l add a service and get those dmesgs

@topjohnwu Alright. so good and bad news.

The bad news is, there is no way i can find to run a script on the device without it breaking after installing magisk (fails to start due to selinux)

The good news is we might have pinned down what exactly goes wrong. if we assume mounting is working well (i dont see any issue with system_root as mirror). something is breaking all services from starting. with this error (took a sample service)

Could not start service: File /system/bin/[email protected](labeled "u:object_r:dsms_hidl_exec:s0") has incorrect label or no domain transition from u:r:kernel:s0 to another SELinux domain defined

The same error repeats for many services. so basically nothing is starting

Here is a snippet of the KMSG the same error is visible in the previous kmsgs.

Note that the /cache/fuckfest.sh is my dmesg logging service. which works until i flash magisk. and returns init: cannot execve('/cache/fuckfest.sh'): Permission denied i think due to selinux label. same as all the previous services. (I have proper exec on this service and it uses the cache file se label and triple checked it working before flashing magisk)

Here is also another snippet of magisk flashed* on full permissive kernel, and non permissive kernel on the same device KMSG . we see the same selinux errors

so TLDR ; something with selinux ? is breaking these services (and possibly more) and it doesnt seem to play nice with the samsung init binary.

Thanks for your time. i hope there is something we can do about this.

@topjohnwu Any updates on this matter ? or any way to provide a proper dmesg, as still with magisk installed all services die

Maybe is there any possibility to inject simple command "dmesg > test.txt" before crash? Or enable extra debugging in kernel source?

Maybe is there any possibility to inject simple command "dmesg > test.txt" before crash? Or enable extra debugging in kernel source?

So far no, I made couple early scripts that do work until magisk is flashed (then it reports selinux context error and does not execute) the same error the services get.

Maybe is there any possibility to inject simple command "dmesg > test.txt" before crash? Or enable extra debugging in kernel source?

So far no, I made couple early scripts that do work until magisk is flashed (then it reports selinux context error and does not execute) the same error the services get.

hmm maybe another way could be possible. Edit source code of dmesg in kernel source to save all gathered logs to file instantly after start without using dmesg command?

Maybe is there any possibility to inject simple command "dmesg > test.txt" before crash? Or enable extra debugging in kernel source?

So far no, I made couple early scripts that do work until magisk is flashed (then it reports selinux context error and does not execute) the same error the services get.

hmm maybe another way could be possible. Edit source code of dmesg in kernel source to save all gathered logs to file instantly after start without using dmesg command?

Do you have any commits for that ? im gonna dig this weekend thanks for the idea

Maybe is there any possibility to inject simple command "dmesg > test.txt" before crash? Or enable extra debugging in kernel source?

So far no, I made couple early scripts that do work until magisk is flashed (then it reports selinux context error and does not execute) the same error the services get.

hmm maybe another way could be possible. Edit source code of dmesg in kernel source to save all gathered logs to file instantly after start without using dmesg command?

Do you have any commits for that ? im gonna dig this weekend thanks for the idea

I have no commit for that. I have found this idea after your answer :P. I moded in this way HID patch to add posibility to disable it.

@ananjaser1211 can you try adding magisk in aroma setup, I have a feeling that it might work.

Exp: Samsung A50 ( SAR Device) Lightrom with magisk installs perfectly and shows.

@ananjaser1211 can you try adding magisk in aroma setup, I have a feeling that it might work.

Exp: Samsung A50 ( SAR Device) Lightrom with magisk installs perfectly and shows.

Unrelated to our issue, Lightrom is Pie and even if your kernel was permissive, this issue is Android 10 isolated. Thanks anyway!

@topjohnwu Any updates on the matter ? Its been days !

@ananjaser1211 I have looked at code van dmesg. I don't think if there is easy way to mod it in kernel. I have another idee but this depends in which step is kernel panic.
Maybe you can insert in init.rc dmesg command to write to file( or insert too dmesg binary in ramdisk)?

Another idee. i see you can boot phone with enforced kernel and magisk. Maybe after success boot can you in terminal emulator get root access and use comand setenforce 0? It makes too kernel panic?

If yes, can you try with USB ADB "dmesg -w" and then in terminal emulator write setenforce 0. Maybe with ADB you can get error like it's getting alltime when boot with permissive kernel?

@ananjaser1211 I have looked at code van dmesg. I don't think if there is easy way to mod it in kernel. I have another idee but this depends in which step is kernel panic.
Maybe you can insert in init.rc dmesg command to write to file( or insert too dmesg binary in ramdisk)?

Another idee. i see you can boot phone with enforced kernel and magisk. Maybe after success boot can you in terminal emulator get root access and use comand setenforce 0? It makes too kernel panic?

If yes, can you try with USB ADB "dmesg -w" and then in terminal emulator write setenforce 0. Maybe with ADB you can get error like it's getting alltime when boot with permissive kernel?

Hi, the bug happens before selinux inits. any custom scripts, rc files logging services that are inserted fail to run and spits out the same selinux error we get on other core services.
(the same excat service runs just fine without magisk being installed)

i have also had the script run in different partitions (cache , data etc) to avoid mounting issues if any, but that did not help, scripts NEVER run under permissive kernel + magisk on oneui Q, i tried alot

Secondly, booting with enforcing is just fine if you are on official Q devices (such as S10 S9) since their sepolicy is already correct that they can run enforcing mode. so they can use magisk just fine anyway

trying to setenforce 0 however, fails even with samsung hard enforce removed from the kernel, the state does not change to permissive, i believe morogoku and corsicanu tried this approach already

The problem with booting "enforced" is really affecting the unofficial Q devices such as the S7 , NOTE 8 , S8 And so on. due to the nature of ported roms, the selinux will ALWAYS fail on enforcing and has to be sepolicy patched with tons of denials in order to just "boot"

Which btw, boots up magisk just fine on the S7 and Note8, aslong as the phone is enforcing the issue does not exist (ofcourse as mentioned permissive on custom roms such as these is a big nono that breaks a ton of stuff)

finally, setenforce 0 also fails on unofficial Q devices with enforced kernel (with no hard enforce)

Hi again @topjohnwu ,

I have found a temporary workaround by setting the kernel to ENFORCE (but without samsung stupid HARD ENFORCE) and made a domain permissive through sepolicy injector then running a .sh script with setenforce 0 under it on init

And now im able to boot our custom ROMs + Permissive with magisk v20.3 installed.
This still does not fix the actual bug of running magisk and force permissive but its a workaround i can live by for now.

photo_2020-03-10_23-20-26

You can just use magiskpolicy to manage anything related to selinux, don't need to use sepolicy injector.

I'll close this issue now, this is not technically an issue with Magisk

You can just use magiskpolicy to manage anything related to selinux, don't need to use sepolicy injector.

I'll close this issue now, this is not technically an issue with Magisk

And yet it is an issue with Magisk since the only way to boot rooted is with enforced selinux. But don't mind it, i heard you are busy redesigning the app instead of fixing real issues.
Just my 2 cents, take it or leave it, i won't care anyway.

Was this page helpful?
0 / 5 - 0 ratings