GCC GSoC 2021 - Static analyzer project

GCC GSoC 2021 - Static analyzer project

[Adharsh Kamath]

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?

Thanks,
Adharsh

Re: GCC GSoC 2021 - Static analyzer project

[David Malcolm]

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'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.

There's no shortage of things to work on in the analyzer (e.g. C++
support, etc).

Thoughts?

Thanks
Dave

Re: GCC GSoC 2021 - Static analyzer project

[Adharsh Kamath]

Hi David. Thank you for the reply.
On Tue, Jan 19, 2021 at 2:12 AM David Malcolm <dmalcolm@redhat.com> 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.

> 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. How do I start with the plugin for
the Linux kernel?

Thanks,
Adharsh

Re: GCC GSoC 2021 - Static analyzer project

[David Malcolm]

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 <dmalcolm@redhat.com>
> 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.

> > 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.

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?

Hope this sounds interesting as a project
Dave

Re: GCC GSoC 2021 - Static analyzer project

[Adharsh Kamath]

On Fri, Jan 22, 2021 at 9:32 PM David Malcolm <dmalcolm@redhat.com> 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 <dmalcolm@redhat.com>
> > 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

Re: GCC GSoC 2021 - Static analyzer project

[Adharsh Kamath]

Hi David,

> 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.
>

I tried this and I understood the control flow in the analyzer.

> 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 implemented a very simple hello world plugin here -
https://github.com/adharshkamath/Hello-world-plugin.
<https://github.com/adharshkamath/Hello-world-plugin>
It just prints a Hello message while building the Linux Kernel, if the
-fanalyzer option is enabled. I referred to the example plugin in the
static analyzer
and the plugins in the kernel source to do this.

> 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 were useful and interesting to read. Thank you for suggesting them.
Adharsh

Re: GCC GSoC 2021 - Static analyzer project

[David Malcolm]

On Thu, 2021-02-11 at 22:35 +0530, Adharsh Kamath wrote:
> Hi David,
> 
> > 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.
> > 
> 
> I tried this and I understood the control flow in the analyzer.
> 
> > 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 implemented a very simple hello world plugin here -
> https://github.com/adharshkamath/Hello-world-plugin.
> <https://github.com/adharshkamath/Hello-world-plugin>
> It just prints a Hello message while building the Linux Kernel, if
> the
> -fanalyzer option is enabled. I referred to the example plugin in the
> static analyzer
> and the plugins in the kernel source to do this.

Excellent.

> > 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 were useful and interesting to read. Thank you for suggesting
> them.
> Adharsh

Great.

I believe you're in a position to write a strong application to GSoC
for yourself for this project; you're well ahead of the timeline, as I
understand it:
  https://summerofcode.withgoogle.com/how-it-works/#timeline

Dave