> Solution:
> Add a cookie as an argument to all libc system call wrapper and libc
> functions. The cookie is initialized during executable load and the
> kernel saves the cookie in struct proc. Then, compares the cookie in the
>
> +       /* initialize system call cookie
> +               cs_cookie is zero, so p->sc_cookie is not initialized in syscall() */
> +       cs_cookie = arc4random();
> +       /* cs_cookie is not zero, so p->sc_cookie is initialized in syscall() */

I think arc4random(3) will return 0 once in a while. How would this
affect the process?

Regardless of that, it seems something like this should be more MI,
and changing stdio.h and fopen() seems totally weird, especially when
not covering all possible platforms.

Lastly, in amd64/trap.c your code goes:

+               p->sc_cookie = arg[0];

but I did not find any decent source in trap.c nor the whole of
/usr/src/sys or /usr/include for where arg[] is declared/defined? That
could just be me being bad at finding stuff though, but looked a bit
odd to me.

Would possibly be interesting to see one example of a program that can
abuse execve() before this patch and not after, and what impact it has
on say "make build" execution times.


--
May the most significant bit of your life be positive.