yashsingh1/xdaforums huggingface dataset:
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
The FlashKernel installer automatically flashes modified libsecure_storage.so libraries and modifies some system props. Possibly this is why you are able to boot that kernel on your set-up.

I can boot the APGK kernel fine on (quasi-)stock BRE5 and BRF3 firmware. BRF8 I haven't tried, but it should at least boot. Users have reported a dysfunctional camera, however.

You said you were running Renovate r79, which is still ARD6-based, I believe; but you had flashed a BRE5 vendor.img over the top.

All in all, that's a lot of mixing and matching, and a lot of scope for unexpected and undesirable interactions.

You have the right idea in wanting to return to a clean base. Ideally, you want your firmware and kernel to be share a common base. That applies to any modified firmware component, too, such as Renovate.

If you can't wait for BRF8, I'd recommend going back to a BRE5 base and stock or very close to stock firmware, such as [MENTION=5150393]_alexndr[/MENTION]'s DevBase.
[Samsung Galaxy S9 & S9+ Cross Device Development] Revontheus:
Thank you for your hard work! One quick question, is there any way perhaps to set the kernel to boot with SE Linux permissive?
[Samsung Galaxy S9 & S9+ Cross Device Development] tiliarou:
BRF8 sources now released: http://opensource.samsung.com/reception/receptionSub.do?method=sub&sub=F&searchValue=G965FXXU1BRF8
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
Version 0.99.4 released

Change log

Updated to upstream Linux 4.9.111.

Rebased to Samsung's BRF8 kernel source code.

Updated boot image to include changes from BRE5 to BRF8.

Download link in OP.

G960F users beware. The kernel for your devices hasn't been tested on a live device. It should work, but that's what they all say, isn't it?
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
Possibly the Magisk SELinux Manager module is the cleanest and most convenient way to achieve this these days. Use with extreme caution, however.
[Samsung Galaxy S9 & S9+ Cross Device Development] jack allen:
Hey im new to your kernel im going to give it a go i just want to ask you about something, i use and im a tester for lightrom and there are some issues with flash kernel and notorious kernel regarding the camera i think a stock kernel may work is this regarded as a stock kernel and if i use it and it works as i hope it does would it be possible for me to put this to lightrom dev and use in his rom obviously im asking for your permission first and he will obviously want to use kernel etc im just the middle man if you will while dev is away on a personal thing. I hope to hear from you please feel free to pm me if you prefer to discuss this in private. Look forward to hearing from you. Jack.
[Samsung Galaxy S9 & S9+ Cross Device Development] smerm07:
does this work on lineage os 15.1?
[Samsung Galaxy S9 & S9+ Cross Device Development] Gmobilize:
Before kernel sources for BRF8 were released, the camera didnt work on any other kernel than stock if you had upgraded to lastest BRF8 base, now it should be working.
[Samsung Galaxy S9 & S9+ Cross Device Development] emphazer:
it works really great with BRF8
[Samsung Galaxy S9 & S9+ Cross Device Development] jack allen:
Thats the thing i am on BRF8 and in light rom it wasn't working even on a clean install and flash kernel im sure thats BRF8
[Samsung Galaxy S9 & S9+ Cross Device Development] Chrispearson172512:
Flash kernel is BRE5
[Samsung Galaxy S9 & S9+ Cross Device Development] Noxxxious:
Try replace your fimc files with the ones from BRE5 in firmware folder, maybe camera will work again.
[Samsung Galaxy S9 & S9+ Cross Device Development] jack allen:
Ah ok i shall give that a go... oh and is there going to be NX kernel for the S9+?? Sorry i just saw your name and i had to ask as i used on my s8+ and i loved it it was by far the best kernel for a balance of performance and battery. I hope you do i really do man id pay for you to make me one hands down i will pay lol. Any way thanks for your reply bro
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
I don't recommend mixing and matching from different versions of the firmware. Even on those lucky occasions when it appears to fix a problem, it can still lead to subtle problems elsewhere that rear their head in obscure ways and are difficult to trace back to their origin.

If you must do it, I recommend making a Magisk module of your changes, because it's so easy to undo them by disabling the module if you get into difficulties. When you actually modify the file system, you have the added hassle of needing to return it to its original state.
[Samsung Galaxy S9 & S9+ Cross Device Development] Noxxxious:
No there will not. This device is terrible and imo not worth spending time on. Besides that the OP makes a solid point that you should make a module, because it will be easier to undo (or you just have the stock base fimc binaries as a flashable zip on the sdcard incase it goes wrong to reflash in TWRP). But if replacing fimc files works, like on S8, then you can use this temporary trick until kernels update to the latest source while sitting on the latest base.
[Samsung Galaxy S9 & S9+ Cross Device Development] pallefar:
First of all, awesome job.

Have you considered adding EAS to the kernel? I see the flash kernel added this and I am wondering if it has a positive effect on the battery life
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
Funny you should mention that, as that's precisely what I've been playing with over the last few days.

An earlier version of EAS is already present in the kernel, as someone pointed out to me a week or two ago, but it's not the version that has since been merged into the mainline kernel.

I've had good results after updating the EAS code to a snapshot from a few months ago (the same one present in ElementalX), but when I pull in more recent commits and repair the conflicts that arise, I see dramatically diminished performance. Actually, I didn't notice the degradation in performance, but I can certainly benchmark it, and it's dramatic enough (> 30%) that it simply has to translate to reduced real-world performance.

I probably made a mistake (or even several) when integrating the code. It's complex and can't simply be dropped into place, because Samsung have made their own incompatible changes to the scheduler. Furthermore, I'm not a kernel engineer by profession, and I've been away from the Linux kernel for many years now (which is why I didn't know about EAS having been integrated), so I don't pretend to be an expert in this area.

Unfortunately, this state of affairs is at odds with the stated intention of this kernel, which is to prioritise stability over all else, so I have to consider where to go from here. I may offer a kernel with the functional EAS code through a testing branch, so that other people can use it if they want to, without having to risk introducing instability in the main branch. That would open up the possibility for more experimental changes, too, which could graduate to the main branch if proven stable in the testing branch. At the same time, I'm cognisant of the increased workload that would result from this, so I have to consider whether it's worth it. After all, there are already established experimental kernels available for those who want to live on the bleeding edge and eke out every last drop of performance from their device.

So, I'm just thinking out loud here. I'm undecided at the moment.
[Samsung Galaxy S9 & S9+ Cross Device Development] pallefar:
Thanks and makes sense. Im sure the new Eas will mature over time for easier implementation. Keep up the good work and stability with the current kernel. As for experimental build, those could be shared when you test. This way you will have a small group of testers. Thanks again
[Samsung Galaxy S9 & S9+ Cross Device Development] emphazer:
man i can tell you.... i tested all kernels so far without notorious (no BRF8 support so far) and i can tell you... its the best so far. really! it works like a charm no problems at all, good battery life and the perfomance just 3-4% slower in benchmark then the overclocked elementalX kernel.

you really know what you are doing and im really happy that you do this and i hope you keep updating it. thanks a lot!

for all ppl which are scared about selinux just install selinuxmodechanger from f-droid!

i did it too because my realtine cpu temperature xposed mod doesnt work with selinux
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
Versions 0.99.5 and 0.99.6 released.

Today brings not one, but two new releases.

The reason for this is that 0.99.5 integrates a fair amount of new code, including an update to EAS (Energy Aware Scheduling) and some code from [MENTION=4167023]AndreiLux[/MENTION] to integrate this with Samsung's own eHMP scheduling.

0.99.5 went through 20 alpha builds on my own device before arriving at the version I'm releasing today. So, depending on whether you are an optimist or a pessimist, the code has either been well-tested (20 builds) or hardly at all (1 device). In actual fact, the truth arguably lies somewhere in the middle, because most of this code is already running in almost identical form in other kernels, such as ElementalX, so it has proved itself in the field. Nevertheless, it is new to this kernel, so approach it with the requisite caution.

Before I could release 0.99.5, Linux 4.9.112 was merged into the upstream Exynos Linux Stable kernel, so I have integrated this into APGK for a 0.99.6 release. This code base has received significantly less testing than 0.99.5, which is why I am taking the unusual step of releasing two versions on one day. You are advised to run the latest version, 0.99.6. 0.99.5 is included for the sake of completeness, and in the unlikely event that the update to Linux 4.9.112 yields a serious issue.

Posting #2 in this thread now contains links to all previously released versions.

Thanks to [MENTION=9116297]Eamo5[/MENTION] for testing the new installer on the G960F and verifying that the kernels for that device do at least boot.

Change log

v0.99.6 (2018-07-12)

Updated to upstream Linux 4.9.112.

Further installer refinements.

v0.99.5 (2018-07-12)

EAS scheduling updated.

16ms PELT half-life for improved scheduling performance.

Kernel optimised for performance over size.

Updated WireGuard to v0.0.20180708.

New installer written in shell.
[Samsung Galaxy S9 & S9+ Cross Device Development] emphazer:
hmm. best benchmark results i ever had with my s9+. very strange.
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
Thank you for the kind words. It's gratifying to read that you have found the kernel useful.

That is strange. Performance should be close to the stock kernel; perhaps very slightly better.

Pretty much every other custom kernel for these devices makes a greater effort to enhance performance, so APGK should theoretically be close to the bottom of the performance benchmark charts, not at the top. Then again, the differences between them are small enough and individual benmark runs erratic enough that the worst run with a performance-enhanced kernel could easily come in behind a fortuitous run with this kernel.

If you perform 10 or more runs with each kernel, you may start to see your numbers average out and become more meaningful relative to each other. Even then, though, there will still be discrepancies between your results and those obtained by other devices theoretically running the same benchmarks on the same kernels, due to differences in background workload, device configuration and environment.

Pragmatic benchmarks based on human perception are the only truly meaningful ones, in my opinion. If you can't tell that a device is faster, it effectively isn't. Likewise, if you can't tell that it's slower, it effectively isn't. And if you can't sense improved or degraded battery life, it doesn't matter whether there is any. Conversely — but equally significantly — just because you believe you do sense a difference, it doesn't mean there actually is one. This detail is often overlooked in the Android community, where supposition is frequently posited as fact, and claimed causal links are seldom demonstrated. That's where profiling and other forms of numeric benchmarking become useful.

Anyway, I do appreciate your enthusiasm. I'd be happy to make this work public even if no-one at all used it, but to hear that someone else does and appreciates it is gratifying.
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
I can't view your image, but it wouldn't affect my answer.

The kernel has no effect on OEM Unlock and, regardless of what your device is telling you, if you have successfully flashed this kernel (and it sounds as if you have), OEM Unlock must be in the enabled state.

If you want to verify this, reboot into Download Mode and scan the tiny text for OEM Lock Off. The message on this screen is always accurate, and thus definitively tells you the state of the OEM lock. The toggle state under Settings, on the other hand, is unreliable on modified devices and usually erroneously claims that the unlock state is disabled.
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
I understand that, but you need to reread my previous reply. If you have installed a custom kernel, your device is already OEM-unlocked. Ignore the state of this toggle: it's inaccurate, but not because of anything that flashing this kernel did. Forget the state of that toggle and never touch the setting again.
[Samsung Galaxy S9 & S9+ Cross Device Development] AndreiLux:
16ms PELT and util_est will have enormous effect on performance.
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
Thanks for your input.

I didn't see huge gains in my testing, but that was limited to some simple benchmarking. I didn't perform any profiling. I did see a performance increase, but it wasn't something to get excited about, even if I took the results at face value without allowing a margin of error for individual benchmark runs.

I ran a bunch of tests with 8ms PELT, too, but saw no obvious difference there, either.

Is there any particular test you favour for highlighting these scheduler improvements?

And are you still actively working on this stuff, or have you moved on to other devices?
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
I just wanted to notify you that mode-switching solutions like SELinux Switch and the Magisk SELinux Manager module will cease to work in APGK 0.99.7. The upcoming release will make it impossible to switch to permissive mode.

I'm curious why some people still want permissive mode. What are you using that requires it?
[Samsung Galaxy S9 & S9+ Cross Device Development] emphazer:
well. for me its just a small thing.

i need it for xposed cpu temperature display.

/sys/class/thermal/thermal_zone0/temp

there is no selinux policy for that module and path.

i would make one by myself but i miss ausearch and audit2allow commands for android.

im very familiar with selinux on rhel/centos 6&7 with modules, compiling .te to .pp files and booleans etc. but android is new for me. do you know a good description or howto page to handle selinux on android?
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
It seems to be governed by the sysfs_thermal role, but I'm unsure why it needs to be so restrictive. Read access doesn't seem dangerous.

To dynamically change the policy, you'll need magiskpolicy, which is a modified version of sepolicy.

For example:

$ adb shell
star2lte:/ $ cat /sys/class/thermal/thermal_zone0/temp
cat: /sys/class/thermal/thermal_zone0/temp: Permission denied
1|star2lte:/ $ su
star2lte:/ # magiskpolicy --live "allow shell sysfs_thermal file { read open }"
star2lte:/ # exit
star2lte:/ $ cat /sys/class/thermal/thermal_zone0/temp
46000

That works for the shell, at least. I'm not sure what you'll need to substitute for the shell parameter in order to get your Xposed module to work, though. Maybe this is enough, maybe not.
[Samsung Galaxy S9 & S9+ Cross Device Development] ULTRAKANGZZZZ:
strong kernel
[Samsung Galaxy S9 & S9+ Cross Device Development] emphazer:
i still use supersu :-/

i have no experience with magisk so far.

i tried to install the manager some months ago and it directly killed my xposed files in the internal sdcard.

so im a bit scared now.

but i will definetly try to switch to magisk if someone can tell me how to use xposed modules with magisk.

i dont even know if its still necessary to install the framework. all I know is. it should be possible.

I think magisk is the future.

but the problem is. its absolutly necessary for me that 3 of my modules will keep running.

xprivacy lua pro

prevent_running

greenify

I really really need them.

and I definitely know that they are selinux compliant!

cpu_temp is just a nice to have.

you gave me the right hook into the right direction.

I got it to work with selinux and a dirty trick.

I run

/system/bin/chcon "u: object_r:sysfs:s0" /sys/class/thermal/thermal_zone0/temp

at system boot and it works.

the sysfs context is readable

sysfs_thermal not. I think it's a bit paranoid because read,open should be allowed for that selinux context.

soooooo, finally I changed my phone to enforced now =)
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
The easiest way by far is to install the Magisk systemless Xposed module. Not only do you guarantee yourself an Xposed installation that is compatible with Magisk, but you also get a master switch for Xposed that you can flip on or off at will; for example, if you need to quickly reboot into a SafetyNet-compliant environment for some reason.

It was with some trepidation that I made the switch myself on all of my devices back in April, after concluding that the reports concerning the death of SuperSU weren't, as I'd first hoped, exaggerated, but a sad reflection of the actual facts.

Magisk has been developed very fast since its inception, and each new release brings a host of new bugs and looping devices. It was way too volatile for my taste, but with the purchase of a new S9+, the time seemed ripe to make the switch.

Since then, I've been won over by Magisk's module feature. You can do a huge amount with it, and it maintains a really clean separation between the base system and the mods you need. If you use Xposed as a Magisk module, for example, any Xposed modules you install will also be systemless.

Xposed works fine for me in this configuration, including Greenify. I don't use the other two modules you listed.

chcon will make the change permanent, won't it? Depending on where in the boot sequence you do it, I suppose.

You may prefer to use SuperSU's supolicy --live, which is analogous to magiskpolicy.
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
Version 0.99.7 released

The most significant change in this release is the removal of support for dynamically switching the kernel to SELInux permissive mode. Running in permissive mode drastically weakens device security, and there's always a better way to enable whatever it is that purports to need permissive mode. Hopefully, almost no-one will be affected by this; and frankly, it was an oversight that previous versions did not enforce this.

Change log

Updated to upstream Linux 4.9.113.

CONFIG_SECURITY_SELINUX_DEVELOP unset. With this change, it's no longer possible to dynamically switch a booted system to SELinux permissive mode.

Further installer refinements to reduce ZIP file size.

Remove support for unused compression types: BZIP2, LZMA, XZ, LZO and LZA4.

Removed support for extracting kernel config from image or running kernel.

Remove support for CONFIG_SLUB_DEBUG.
[Samsung Galaxy S9 & S9+ Cross Device Development] xdauser'17:
can you please tell me what libsecure_storage originally used for?

the cause is that im trying to compile kernel for galaxy s8, it's now able to boot, but wifi wont work, and force encryption cant be turned off even after changing forceencrypt to encryptable in /system/vendor/etc/fstab.qcom. just as you said, some custom kernel's flashable zip file includes this library, so tried to google it, and it led me here.

maybe it's a bit off-topic, but if you'd like to tell me? :laugh:
[Samsung Galaxy S9 & S9+ Cross Device Development] saxmydix:
Hi good sir, any plan to port your kernel for AOSP soon? Since we don't have any custom kernel for AOSP, I think it's good thing to have variation for kernel too. Thanks.
[Samsung Galaxy S9 & S9+ Cross Device Development] Revontheus:
I am aware of the security risks running Permissive entails however one of my modifications, namely, ARISE (which is basically Viper4Android + Dolby Digital Plus) requires a permissive workspace to function correctly. Would there be a possible workaround for apps like the aforementioned?

Thank you for your hard work!
[Samsung Galaxy S9 & S9+ Cross Device Development] WhoIsJohnGalt1979:
Please use viper through magisk and you don't need permissive mode.
[Samsung Galaxy S9 & S9+ Cross Device Development] GeyerA:
Hi, I am facing issues with Wireguard. Built kernel for Pixel and Wireguard worked. Built kernel for S8 and S9, Wireguard does not work. Flashed this kernel, Wireguard still does not work. Posted in the Wireguard thread but removed my post so I am asking here if somebody successfully uses Wireguard. I am with Azirevpn (also using on my Debian machine). Screenshot and log file below (BTW, I am on _alexndr's ROM).
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
libsecure_storage is a library that handles the encrypted storage of sensitive user data, such as Bluetooth pairings and wi-fi passphrases.

Wi-fi will probably work if you manually enter the passphrase. I suspect the device is unable to decrypt the currently stored hash when the stock kernel is replaced.

Forced encryption is an unrelated matter. Turning it off in the fstab should work, otherwise modifying the DTB if this version of the OS now uses that instead of the fstab. I assume you've tried modifying the fstab, formatting /data and rebooting to Android. If that resulted in the device becoming re-encrypted, try modifying the DTB instead.

The sources I provide are for the G960F/G965F, so I've no idea what modifications you're making to produce a working kernel for your device. Are you building a suitable DTB, too?
[Samsung Galaxy S9 & S9+ Cross Device Development] farovitus:
https://twitter.com/EdgeSecurity/status/988450325576192001?s=19

https://play.google.com/store/apps/details?id=com.wireguard.android

According to the tweet, you can use the app in the link above without kernel support, give it a shot
[Samsung Galaxy S9 & S9+ Cross Device Development] GeyerA:
Hi, thanks. Already installed, but as mentioned before, never got it to work on Samsung just on Pixel...https://xdaforums.com/pixel/development/reference-pixel-kernel-source-linux-t3717141/page2

Bugger, seems working after all....:)
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
I'm not totally sure what you're asking. When you say AOSP, what do you mean in the context of the S9/S9+?
[Samsung Galaxy S9 & S9+ Cross Device Development] ianmacd:
The Dolby portion of ARISE claims to need permissive mode. Viper4Android itself definitely doesn't.

The right way to fix this is to run ARISE with SELinux in enforcing mode, note the errors, and then institute specific, limited measures to make this one package run properly. Or take the shortcut of asking the developers why permissive mode is needed.

The wrong way to do it is to recompile the kernel with CONFIG_SECURITY_SELINUX_DEVELOP re-enabled, and switch to permissive mode during boot. Even if this were the only way to get ARISE's Dolby Digital working, it would still be a horrible trade-off in my opinion. Nevertheless, having the source available means that any user who disagrees with my compile-time decisions is at liberty to compile a kernel that precisely fits their needs.