"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
Where were you when I asked you about UDEREF? Oh that's right, no answer. This really shows how much you really colaborate with people.
2
1
speaking of collaboration, last i looked we provided you with a lot of help way back in last november already whereas you gave us exactly nothing back, despite your promise to keep us in the loop about your findings. how do you explain that?
1
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!
@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
"Interrupt handlers are executed when the kernel is in interrupt context, i.e., it is not associated with a task, therefore, the unreadable kernel stack feature (prevents cross-task information leaks and corruption) is insufficient."
1
i was waiting on you to deliver on your promise you made last november to me but clearly failed to do so. at the beginning i assumed you approached us in good faith but clearly all you can do is ad hominem attacks and not actual research.
1
So what does assuming arbitrary r/w mean? gdb does just that, and it's easier for people to understand (not that you have experience with that). If you say so... I can't really verify that.
1
it's described in my H2HC15 presentation that you even linked to (reference ) but clearly never read or understood.
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
that said, what do irq stacks have to do with unreadable kstacks? what makes you think the interrupted process stacks remains readable when the kernel switch to the irq stack?
1
next, irq stacks are not in .data, but percpu allocated. also interrupt context is always associated with a task, the one that was interrupted, it's just not something specific the irq handler can rely on so it has to schedule work in process context if it needs such.
1
Weird that LWN publishes the blogs of many other companies (most recently Google) and rarely do I ever see them use phrases like "if one looks past the advertising" like they did for ours for simply mentioning that we have an independent backport process and a plugin for Spectre
3
2
11
PaX Team retweeted
Teardown of a Failed Linux LTS Spectre Fix (alternatively: Sweeping Study of a Spectacular Stable Spectre Screwup) grsecurity.net/teardown_of_a… wherein we demonstrate the value of Respectre and an independent and funded security backport/review process for the Linux kernel
1
25
2
42
today's quiz: find the infoleak bug introduced by upstream commit 85164fd8b05320 that was caught by a recent rewrite of our structleak GCC plugin.
1
4
13
Yes but probably too much churn; do you find this sufficiently clear (moved after the description of new_prot and set_max): Whether set_max is TRUE or FALSE new_prot may not include any protection bits that are not already set in max_protection on every entry within the range.
1
Of course :)
Same question came up in the code review, resulting in a clarification in the man page: svnweb.freebsd.org/base?view…
1
i see, though it still kinda only implies it since 'new_prot' can either be the new value for 'prot' or 'maxprot', doesn't make it easier on the reader ;). i'd have probably forked this into two separate functions setting prot/max_prot respectively instead of the bool selector...
1
as for using this for secure JIT support, it's not going to cut it, the proper way is out-of-process JIT (in general, the generator and consumer address spaces must be separate, among others).
1