On Fri, Jan 22, 2021 at 9:32 PM David Malcolm wrote:
>
> On Fri, 2021-01-22 at 20:46 +0530, Adharsh Kamath wrote:
> > Hi David. Thank you for the reply.
> > On Tue, Jan 19, 2021 at 2:12 AM David Malcolm
> > wrote:
> > > On Thu, 2021-01-14 at 10:45 +0530, Adharsh Kamath wrote:
> > > > Hello,
> > > > I came across the list of possible project ideas for GSoC 2021
> > > > and
> > > > I'd
> > > > like to contribute to the project regarding the static analysis
> > > > pass
> > > > in GCC.
> > > > How can I get started with this project?
> > >
> > > Hi Adharsh
> > >
> > > Sorry about the delay in responding to your email.
> > >
> > > Thanks for your interest in the static analysis pass.
> > >
> > > Some ideas on getting started with GCC are here:
> > > https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply
> > >
> > > The analyzer has its own wiki page here:
> > > https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer
> >
> > I examined the analyzer dumps for a few programs. I also read the
> > documentation on the internals of
> > the static analyzer and I've understood the basics of how the
> > analyzer works.
>
> Excellent. Building GCC from source and stepping through it in the
> debugger would be good next steps. You'll need plenty of disk space.
> "run_checkers" is a good breakpoint to set if you're looking for the
> entrypoint to the analyzer.
Yes, I'll try this.
> > > I've actually already implemented some of the ideas that were on
> > > the
> > > GSoC wiki page myself since last summer, so I've updated that page
> > > accordingly:
> > >
> > > https://gcc.gnu.org/wiki/SummerOfCode?action=diff&rev2=187&rev1=184
> > > I've added the idea of SARIF ( https://sarifweb.azurewebsites.net/
> > > ) as
> > > an output format for the static analyzer (and indeed, for the GCC
> > > diagnostics subsystem as a whole).
> > >
> > > Do any of the ideas on the page look appealing to you? I'm open to
> > > other ideas you may have relating to the analyzer, or indeed to gcc
> > > diagnostics.
> >
> > Yes. Making a plugin for the Linux kernel seems very interesting to
> > me.
> > I'd also like to extend support for C++ but I'm not sure if both
> > ideas would be
> > possible, given the time constraints.
>
> I think that picking just one would be better than trying to do both.
>
> > How do I start with the plugin for
> > the Linux kernel?
>
> I added plugin support to the analyzer in:
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=66dde7bc64b75d4a338266333c9c490b12d49825
>
> There's an example plugin in that patch. The kernel source tree
> already has some plugins, so hopefully those together give some
> pointers on how to write a "hello world" analyzer plugin that runs as
> part of the kernel build, which would be another next step, I guess.
I will go through the plugin in the kernel source tree and try to write a simple
analyzer plugin.
> Unfortunately I'm not a Linux kernel developer, so I don't have deep
> knowledge of what checks would be useful and the subtle details that
> are likely to be necessary. I'll try to reach out internally within
> Red Hat - we have plenty of kernel developers here.
>
> Some ideas:
> * detecting code paths that acquire a lock but then fail to release it
> * detecting code paths that disable interrupts and then fail to re-
> enable them
> * detecting mixups between user-space pointers and kernel-space
> pointers
>
> The kernel has its own checker called "smatch" which may give other
> ideas for warnings.
>
> The state machine checker in the analyzer takes its inspiration from
> the Stanford "MC" checker (among other places, such as typestate),
> which has been used to implement warnings for the Linux kernel, albeit
> some very old versions of the kernel.
>
> See::
> * "How to write system-specific, static checkers in Metal" (Benjamin
> Chelf, Dawson R Engler, Seth Hallem), from 2002
> * "Checking system rules using system-specific, programmer-written
> compiler extensions" Proceedings of Operating Systems Design and
> Implementation (OSDI), September 2000. D. Engler, B. Chelf, A. Chou,
> and S. Hallem.
> * "Using Programmer-Written Compiler Extensions to Catch Security
> Holes" (Ken Ashcraft, Dawson Engler) from 2002
>
> These are working on 20-year-old in-kernel APIs that might be obsolete
> now, but they have examples of interrupt checking, and user-space vs
> kernel-space pointer checking.
>
> Focusing on error-handling paths in driver code might be best.
>
> Does this answer your questions?
Yes. Thank you very much for these resources. I will go through them.
Adharsh
