"Control-Flow Integrity for the Linux kernel: A Security Evaluation" is the work I've done for my Masters thesis where I analyze how the PaX Team's (public) RAP holds up to stop ROP when applied to the Linux kernel. You may want to check out chapter 3. alunos.dcc.fc.up.pt/~up20140…
6
66
5
204
this is a sad joke for a 'thesis' i'm afraid. you should have kept true to your word and kept us in the loop about your findings to avoid all these errors.
1
You should also keep true to your word and assume defeat as I've found ways to bypass RAP on the public test patch?
6
3
Replying to @uid1000
you didn't find anything. section 3.2 describes a situation with KERNEXEC (not RAP), on amd64 (not i386), on grsec (not PaX), on an insecure config, needs root (how did you gain that again? oh wait, you couldn't figure that out :). sorry, no dice for this one.

Sep 18, 2019 · 9:38 PM UTC

1
Replying to @paxteam
I specifically say it's a KERNEXEC issue (did you read the title?) that allows code injection (thus, allows for a RAP bypass) on PaX/grsecurity systems. Apparently, it doesn't even need an insecure config!
grsecurity @grsecurity
13 Sep 2019
@uid1000 you should really have had us review this before you presented it ;) ./coredump.c:char core_pattern[CORENAME_MAX_SIZE] __read_only = "core";
1
you're saying contradicting things. it's either a KERNEXEC issue or a RAP issue, make up your mind. and you're still making the false claim that it has anything to do with PaX (as i said already, it's grsec only) but prove me wrong (or retract).
1
more replies