Also, when parsing a function definition, why does smatch only follow some internal function calls? For example, in the syscall `get_mempolicy` in ``mm/mempolicy.c`, it will follow the call to `copy_nodes_to_user`, but will not follow `do_get_mempolicy`. Is there a way I can make it follow all internal function calls? On Fri, Sep 29, 2017 at 3:23 PM, Andrew Zhu Aday <andrew.aday@xxxxxxxxxxxx> wrote: > Hi Smatch, > > I ran across a bug: when running `~/smatch/smatch_scripts/kchecker mm/msync.c`, > I noticed that FUNCTION_CALL_HOOK and CONDITION_HOOK are not actually > called within the body msync. Some other syscalls I looked at seem to > work correctly. > > Do you know why this is the case? Is there a simple fix? > > Thanks, > Andrew > > On Fri, Sep 29, 2017 at 3:23 PM, Andrew Zhu Aday > <andrew.aday@xxxxxxxxxxxx> wrote: >> Hi Smatch, >> >> I ran across a bug: when running `~/smatch/smatch_scripts/kchecker >> mm/msync.c`, >> I noticed that FUNCTION_CALL_HOOK and CONDITION_HOOK are not actually >> called within the body msync. Some other syscalls I looked at seem to work >> correctly. >> >> Do you know why this is the case? Is there a simple fix? >> >> Thanks, >> Andrew >> >> On Sat, Sep 23, 2017 at 1:37 AM, Andrew Zhu Aday <andrew.aday@xxxxxxxxxxxx> >> wrote: >>> >>> Hi Smatch team, >>> >>> My name is Andrew Aday and I'm an CS undergrad at Columbia University. >>> >>> I'm currently doing research on kernel fuzzing via the system call >>> interface, >>> and I'm at the point now where I need to track "implicit dependencies" >>> between >>> system calls. I'm writing this email to ask: how appropriate is Smatch >>> for this task? >>> >>> To explain: >>> >>> Syscall A is an "explicit dependency" of syscall B if A produces a >>> resource which B >>> uses. For example `open` and `read` >>> >>> Syscall A is an "implicit dependency" of syscall B if A can affect the >>> control flow/coverage of B, but B doesn't use A's return value. For >>> example, >>> `mlockall` and `msync`; calling `mlockall` before `msync` will cause >>> the latter to >>> fail with -EBUSY, and thus influences its control flow. >>> >>> My naive approach: >>> >>> Use static analysis to build out the CFG for each syscall, and create a >>> mapping >>> from each system call to the global variables it accesses. Mark two >>> syscalls >>> as implicitly dependent if the intersection of their global var >>> accesses is nonempty. >>> (After pruning the especially common ones e.g. GFP_KERNEL) >>> >>> I've looked briefly at Smatch, but I wanted to get your assessment >>> before I go any >>> further. Is what I'm trying to do feasible? I see there's a >>> `FUNCTION_CALL_HOOK` >>> I can plug into to recursively collect all the global variables under >>> a given syscall. >>> But I'm very unfamiliar with static analysis in general, so I'm not >>> sure about how >>> straightforward doing this is. >>> >>> Please let me know your thoughts! And of course ask me any questions or if >>> I >>> need to explain better. >>> >>> p.s Why does the cross-function database become more accurate every >>> time it's rebuilt? >>> >>> Thanks! >> >> -- To unsubscribe from this list: send the line "unsubscribe smatch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
