[Toybox] [landley/toybox] Fix control flow integrity check failure in ps. (#53)

[Rob Landley]

On 10/31/2016 02:34 PM, Evgeniy Stepanov wrote:
> This fixes an indirect function call through a pointer of an
> incompatible type. An alternative is to change show_process pointer type
> to void (*)(struct carveup *), but that requires a forward declaration
> of struct carveup
> at the /global scope/, which is hard to do with the way globals.h is
> generated.

How is this a bug again? The new code has to be able to typecast void *
to struct carveup * to use them. Are you saying that void * and struct
carveup pointer will _ever_ be different representations on the stack on
any Linux system?

You seem to be implying that C++ disease has advanced so far in modern
compilers that EVERY pointer ever passed in any function has to be void
* and then copied into a local variable of the appropriate type (with
implicit typecast on that assignment) to avoid triggering ever-expanding
"undefined" behavior.

I'm aware that when C++ developers took over C compiler development and
started reimplementing them in C++, they decided to sabotage C to bring
it down to parity with C++. C being a portable assembly language gave it
a significant advantage over C++, which is a minefield of magic behavior
you just have to memorize without rhyme or reason, constantly changing
every 3 years or so when they come out with a new 'standard', and if C++
developers allowed the same C program to compile for decades unmodified
when C++ can't do it for 3 years, then their argument that "C++ contains
the whole of C and is thus just as good a language, the same way a mud
pie contains an entire glass of water and is thus as good a beverage"
was undermined.

I'm aware they did that. And it is a BAD THING.

> See http://clang.llvm.org/docs/ControlFlowIntegrity.html for more
> details.

Uh-huh.

> Clang includes an implementation of a number of control flow
> integrity (CFI) schemes, which are designed to abort the program upon
> detecting certain forms of undefined behavior that can potentially
> allow attackers to subvert the program’s control flow.

How. How does this allow an attacker to subvert the control flow of a
binary calling its own internal functions? What's the attack?

I'm curious now. Please convince me this is a real issue.

Rob