This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/59856] Support sparse-style context checking, used to validate locking correctness


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59856

--- Comment #12 from PaX Team <pageexec at gmail dot com> ---
1. there's a (linux) kernel-hardening effort of late that among others will try
to upstream the PaX gcc plugin infrastructure along with some plugins, so the
checker one could be added to that list (but it wasn't part of the initial
plan). you should probably continue this thread on that list instead as i doubt
many kernel devs follow the gcc bugzilla ;).

2. as for my idea, it's simple: track the context via an artificially injected
local integer variable (one per context if you want context sensitivity) and
initialize it to the 'in' attr parameter or 0 otherwise then adjust its value
on function calls that affect it based on the callee's context attribute. at
the end compare the variable against the 'out' attr parameter (or 0) and
complain on a mismatch (in my proof-of-concept i just called builtin_trap on a
mismatch). now where gcc comes in is that it'll do constant propagation, DCE,
etc for free so the final check either gets removed by dead code elimination
(the locking is correct) or we detected a locking problem and can even
determine the bad path(s). using this simple method on Josh's test file
there're no false positives or false negatives. i'll work it into something
usable (actual reports instead of having to check for leftover builtin_traps)
and release it in PaX then linux can pick it up when the time comes.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]