Replying to @0xMatt
Well these aren't particularly important issues, we don't talk about the important ones ;) It's more of an interesting experiment to see what happens with the information once it's out in the wild. I point out the credit issue merely because it is a constant theme
1
That said, I think it's fine for people to unwittingly do Google's LLVM plugin bidding without pay (that it should be funding itself) but there's a bit of hubris involved to assume you considered all the things in a particular security implementation that the original authors did
1
I was reminded recently when trying to look for references of the pervasiveness of PaX's ASLR for instance that it seems that if you don't speak up, someone else will rewrite history for you in their or someone else's favor: security.cs.rpi.edu/courses/… security.cs.rpi.edu/courses/…
3
1
6
Well, while *ASLR* was first publicly implemented by PaX, memory layout randomization was also discussed before ASLR. Even though their not the same, one might think that was a step towards PaX ASLR.
2
1
Using the same logic, PaX can't claim CFI started with him in pax-future.txt. Those were just ideas, not an implementation. Also, there's no "forward-edge" checks in there...
2
Showing the actual instruction encodings of the checks isn't "just ideas" -- this is regurgitated Payer nonsense, the same thing for the forward edge checks, which look exactly the same as the return checks (a return is just another indirect control flow after all).
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
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, would you like to share for historians what CFE was and how was it supposed to work?
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.

Mar 22, 2019 · 12:09 AM UTC

1
Thanks, and no problem :) probably something along the lines of a "shadow stack".
1
nope, shadow stacks are runtime constructs, CFE isn't.