The porting work of the PaX patch already done. We tested it with Towel & KINGROOT. The result as expected: they all failed to root the Android 5.0.2 with kernel code base from 2014. Perhaps, we might try to make GRSEC & RBAC into the Android in the future………

Some friends asked me what's the most headache things during the porting job. Well, I guess porting PaX/Grsec is similar to any other porting work. | read the fuc*ing source code-->compare->merge->compile->debug | and, that's it;-)

Thanks to the PaX team and Spender and some other dudes who contribute to PaX/Grsecurity( more or less). PaX/Grsecurity has been making defense-in-depth in kernel level for real.

The porting strategy is missing some steps When we port to another kernel, we also ensure that the new code present in that kernel doesn't somehow undermine our protections. We perform regression tests against every distributed patch and maintain backports of security fixes across all supported kernels. FTR, the PaX patch contains very few security backports -- at least 95% of them are entirely in the grsecurity patch. I appreciate your enthusiasm, but there's a lot more effort that goes into officially supported patches.

For transparency, what was the filename/date of the PaX patch used as the basis for the port?

spender wrote:The porting strategy is missing some steps When we port to another kernel, we also ensure that the new code present in that kernel doesn't somehow undermine our protections. We perform regression tests against every distributed patch and maintain backports of security fixes across all supported kernels. FTR, the PaX patch contains very few security backports -- at least 95% of them are entirely in the grsecurity patch. I appreciate your enthusiasm, but there's a lot more effort that goes into officially supported patches.

That's for sure. I only did this port as a PoC to prove it to myself that Android can be protected under PaX/Grsec. So there are indeed a lot of missing parts, including new features( UDEREF, etc) and some other hardening code. I may continue the further work if I could find the slot in the future.

spender wrote:For transparency, what was the filename/date of the PaX patch used as the basis for the port?

-Brad

Ohh, s0rry about that. This work is based on: pax-linux-3.4.8-test32.patch. And I also takes pax-linux-3.2.69-test175.patch & pax-linux-3.8.13-test24.patch as reference ones.

Ideally, Intel would wipe the floor with ARM on mobile and we wouldn't have to deal with this insanity anymore .

The Copperhead kernel repositories (Samsung S4 and Nexus 5) for 3.4 aren't much different from what you've done. I don't think it makes much sense to invest a lot of time in 3.4 at this point because new Android devices are starting to ship with the 3.10 kernel and the lifetime of PaX's 3.2 LTS will be coming to an end. The main reason they're not yet public is because I didn't want my efforts to be judged based on an early proof of concept.

The OS will probably be alpha/beta-quality for the lifetime of 3.4, so significant improvements over vanilla while not matching a true grsecurity kernel with features beyond the PaX baseline and more security backports than Google/CyanogenMod provides is perfectly fine. Android is a lot more than the kernel, and most of the effort is going to be focused elsewhere in userspace. Spending less time on a kernel for old devices means spending more time on work that's going to be useful for a long time. Lots of the userspace improvements can also be upstreamed without too much of a struggle, which means spending more time developing new stuff instead of rebasing over and over and then migrating code to new Android versions.

I'd like to do a higher quality port for the 3.10 msm tree and closely follow the upstream 3.14 LTS, but I need to get my hands on a device that's using 3.10 first. This could be mature by the time 3.10 is the most common Android kernel and would hopefully last for some time.