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
