Correct me if I'm wrong, but I don't see any emails from any of the listed authors having requested anything and being denied: arxiv.org/pdf/1905.10311v1.p…
2
8
My bad, I haven't thought it would be as easy as just asking you for it. Could we arrange it now? I'd really appreciate if we can compare our results with Respectre.
2
1
looks like FreeBSD (in)security is in very (in)capable hands: youtube.com/watch?v=7kShjboN…
5
5
1
23
github.com/clang-randstruct/… 🤔not the only bug, but I don't assist people who don't even mention the original authors of the code they ported
1
9
And as I said already, pax-future.txt (your doc) says that function pointers were "different" (c.2). I'm just quoting it.
1
I should write a kees_cook.py script that collects all the bug reports from the kernel bugzilla and emails them to LKML so that I get the sole "Reported-by:" tag for thousands of other people's findings.
2
5
This doesn't even make sense and is obviously false. I once again regret attempting to engage with you. I spent years trying to help bridge the gap between you and upstream only to have your toxicity poison it every time. I'll go back now to ignoring your subtweets.
2
6
You described the *exact* same thing for rets, not calls/jumps. CFI is an extention of that. While it's obvious you had an influence in its creation, we can't really say you invented it. Noone is blaming you for not being funded for your work.
1
as i said already, the type hash was *exemplified* with returns, it's obvious that the same defense (down to the machine code sequence) works for calls too as you can see it in RAP/FPValidator. but then again this was written for subject matter experts at the time, not laymen :).
1
i made a brief mention of it at my SSTIC'12 keynote (and perhaps later too). it stands for Control Flow Enforcement and does just what the name implies, it forces control flow along a path that is determined by read-only data. the implementation details are not public, sorry.
1
Sure, but it's now clear that in some cases fptrs can't be made read-only. That's why CFI is needed (while not a cure-all, there's still (3) as you know), and why inventing CFI can't be credited to you. Thanks for being someone people can have a sane discussion with.
3
also, fptrs can be made effectively read-only (the logic behind KERNSEAL can do it for any kind of data) but i'm not sure the performance impact will be practical.
1
who else invented it before me then? i know of no prior work that identified both the problem and the solutions. do you?
1
Then why didn't PaX talk about protecting forward edge checks? After all, he says they're "different" in pax-future.txt (c.2)
2
nitter.vloup.ch/paxteam/status/1… is the answer. also at the time i thought it'd be feasible to make all fptrs read-only (and thus not worry about their integrity) whereas i couldn't imagine that for retaddrs (i did solve it later but it turned out to be impractical, CFE was the name).
nope, read nitter.vloup.ch/paxteam/status/1… again and understand what exemplify means. for background, all these docs were written during a short contracting gig in 2002 for subject matter experts at the client who were already familiar with my work, academic publication wasn't the focus.
1
I'm not saying PaX should he left out of history, where did I say that :) all I'm saying is that PaX did not coin CFI nor did he first implement it. Isn't that a fact?
2
i didn't call it CFI but i had described the *exact* same thing that was later rediscovered by academics (in fact, it seems that my threat model was even more generic than anyone else's then or since). correct about the implementation, but then noone funded my work either.
1
I see you mentioning ALSR but not the claim that i'm actually refering to: PaX saying he deserves credit for CFI. pax-future.txt has *some* ideas, not all. You see what I'm trying to say?
3
you should read a bit more than just that one doc. there's pax.txt for a start which defined the very exploit (and thus defense) categories that we now take for granted. e.g., out-of-intended-order execition -> code reuse/*OP, in-intended-order execution -> data only attacks.
1
github.com/llvm-mirror/llvm/… academic research not at its best. it took too long considering how since the beginning the only realistic threat model was 'arbitrary read-write' (slide 5 in pax.grsecurity.net/docs/PaXT…). i hope that people won't waste another 2 decades on such 'defenses'.
3
12
i'd propose to name the upcoming linux 5.0 kernel as Easter Egg Hunt Come Early and kick it off with 61cb5758d3c46bc1ba87694fefc0d9653613ce6b.
2
3
7
look at what the cat^W^Warxiv has just dragged in: arxiv.org/abs/1902.10880 . finally someone dispels a myth, many more to go :).
16
1
23
KSPP fairy tale du jour: openwall.com/lists/kernel-ha… … (hint: if RANDKSTACK was inspired by stackjacking then how could the supposed inspiring presentation have talked about it? perhaps because in reality it had already existed for almost a decade? :))
2
5
12
Hi pipacs! IIRC, RANDKSTACK was implemented in the early 2000s, and then was ported to amd64 after our presentation. Is that accurate?
1
RANDKSTACK was born on i386 in 2002 or 2003, i forget now, the amd64 version is from 2011 after the HES presentation. what that presentation did inspire was STACKLEAK though and my career in gcc plugins (after i'd procastrinated^Wwasted my time in the llvm world for too long :P).
1