[Galaxy Note Pro 12.2 Original Android Development] esgie:
Your two posts above confirm that SU version was not the issue, as it is still preventing from modyfing anything related to kmem, sorry for effort, attough hope you'll at least enjoy included, almost-working twrp, as it seems to be only one capable of flashing zips and doing backups and restoring them on p905 floating around (if you use exfat card for everyday use, my recommendation is to use another one, ie. 8 gig, which are cheap as hell, format it to fat32 (in android it's recognized as vfat) and use it for exclusively for backup purposes, at least until someone establishes a better solution. It's not that bad after all plus it gives you real possibility of experimenting with the device without need to worry about configuring it again from the beginning if something fail. Btw please be aware if in any case, after restoring backup/flashing zip/clearing cache you'll receive a bootloop AND/OR after booting you/apps won't be able to write to any part of internal memory (like /sdcard or /cache), just get back to twrp, use console and run restorecon commands for all partitions AND -as restorecon will break su - reflash su. ALSO - if anytime TWRP on exit will prompt you with a proposition of rooting the device itself - don't do that, the only proper way of fixing su is reflashing it from the genuine zip (or with odin, but avoid that as cf-root includes older version). Uh, isn't it a offtopic? Sorry..

The kerne IS stock (as to the binary part) but with modified ramdisk (repacked) including changed policy of accessing /dev/kmem. If you have kernel warranty bit warning on boot, you have flashed it succesfully ( the message will disappear when you flash back FULLY-stock kernel back - also, i dunno why but it says "kernel is not enforcing" but it's not YET true! It will say the same even if I repack kernel without any changes, so it's quite misleading...), although kernel version/compilation number nor any extra features will not change in the system coz the kernel base is absolutely the same (and it has to stay the same until Samsung release sources that work, coz current one won't).

To really, really confirm that you have flashed my kernel and that the policy of writing to memory has been removed, please open /file_contexts file (it lies in the very root of the filesystem) in any text editor within Android, and look for lines with /dev/kmem or /dev/mem. They should be commented out by "#" in the beginning - or deleted at all (dont remember which one method I did use...). If so, you can be sure that you have flashed repacked kernel succesfully (and also that I have uploaded the proper one, with changed policy...).

If you have checked above, you may be sure that after every boot to Android, now, the new policy (without restrictions to /dev/kmem, which were commented out/deleted) will be loaded. I don't think that restorecon -R /dev will be no longer necessary after that, as the /dev directory is virtual and created on every boot, so its previous, restricted security labels are not preserved between reboots and they are assigned according to current policy, only - but you can run it to check if you see any errors for /dev/kmem (and you should NOT see them... there might be other, like for /dev/cpuctl etc, but it doesnt matter...).

After that, there should be no further doubts that you have unlocked /dev/kmem for writing!

On this step you still need to run the command from my post on top of the topic, this one:

su
printf '\x00' | su -c dd of=/dev/kmem seek=$( printf '%d\n' '0x'`cat /proc/kallsyms | grep ".*\ selinux\_enforcing" | cut -f 1 -d " "` ) bs=1 count=1 conv=notrunc

setenforcing alone WILL NOT WORK EVEN NOW, only the script above helps. I guess you avoided that after flashing kernel, coz of misleading boot warning...

Then check enforcing status. Now it really should work.

If we achieve a success, I'd rather release a fully-featured-repacked-kernel, with built-in kmem script, so it will be permissive from the very beginning (PLUS it will be in a good mood to close possibility of further writing to /kmem after that one single write, as it is really serious security hole, to be honest, to let anyone write to any part of memory directly..., and also include init.d support out-of-the-box as well).