[AT&T Samsung Galaxy Note 4] FiniteTime:
Half-reboot is a good workaround.

But for finding permaroot I'm thinking it would be good to find out two things:

Would dumping all of the /dev/block/mmcblk0p* files (/dev/block/mmcblk0p1 through /dev/block/mmcblk0p26 as far as I can tell) give more info than what is already present in the tar.md5 files?

If you temp root, find repeated 00s in /dev/block/mmcblk0p* files, change 2 of them to say FF, then reboot, do any of the changes to the block devices stick for any?

Writing straight to /dev/block/mmcblk0p* files may be too easy, but I think it's worth ruling out.

Updates have to have write access, but if that's protected by some crypto chain of trust I'm not sure.

Another longshot is at some point in the boot process /dev/block/mmcblk0p* files change from rw to ro then undoing whatever the operation is. (I recognize this is super naive but thinking in terms of "mount -o remount,rw")

Most likely method right now seems to be removing write protect in the kernel. Which requires an unsigned module that disables the write protection (or say if write has been removed from the driver, using a compiled driver from source or one from the Verizon Dev Phones).

I see talk about having a kernel module that allows unsigned kernel modules to be loaded, which sounds like it would work fine and probably make testing easier, but all we need is removal of write protection and one kernel module that does that, rather than one that allows loading unsigned modules and a separate module to remove write protection seems like potential extra work.

I just hope the people working on the unsigned kernel module effort are reaching out to people that have worked on it in the past. I personally am quite curious about:

What specific protections there are that prevent loading an unsigned kernel module?

Actions that root is unable to take in a modern locked-down Android environment due to dm-verity, say disabling dm-verity, or disabling what keeps the kernel from loading unsigned modules.

Actually I guess dm-verity would keep modifications to /dev/block/mmcblk0p* files in important places from being useful. But maybe it doesn't check them all.

I suppose it could be a catch-22 of to disable dm-verity you need to write out the config, but you can't write anything due to the chain of trust with dm-verity and the like.

A really dirty workaround that is probably too limited to work but doing something like a kexec of another kernel under the temp root, which may be what hsbadr has done or is thinking.

These new 4.4 protections are too new and too annoying. ;/

EDIT:

Quick Google about Samsung and dm-verity brings up posts about the Note 4:

http://xdaforums.com/note-4/help/dm-verity-verification-failed-recovery-t2945531

http://forums.androidcentral.com/sa...eset-dm-verity-verification-failed-error.html

http://www.sammobile.com/forum/showthread.php?t=24456

from: https://www.google.com/search?q=samsung+dm-verity

So we do have dm-verity even in in KitKat as some posts are from before the Lollipop update was released.

dm-verity has to be disabled or modified in our phones if it checks say system or other places we need to modify for permaroot.

Just a guess, but the temproot may be due to some dm-verity or similar layer that checks if new writes pass a crypto check, and if they don't, it falls back to what was there before (like a 'restore point' Microsoft Windows does).

EDIT 2:

Reading up on dm-verity ( http://nelenkov.blogspot.com/2014/05/using-kitkat-verified-boot.html ) makes me think that dm-verity is involved in reading, not writing. So it sounds to me that android just does a unionfs with a ram filesystem (maybe tempfs).

I don't really get what restrictions there are on what root can do. Since apps have to write out data, and log files are written, seems like anything like that the temp root should let one do.

On a standard Linux box if there was a unionfs with a ramfs I would just "sudo mount /dev/sda2 /mnt" (assuming sda2 is /) and go to town. I would *really* like to know what stops that here, as in selinux, or dm-verity, or what.