* GCC GSoC 2021 - Static analyzer project @ 2021-01-14 5:15 Adharsh Kamath 2021-01-18 20:41 ` David Malcolm 0 siblings, 1 reply; 7+ messages in thread From: Adharsh Kamath @ 2021-01-14 5:15 UTC (permalink / raw) To: dmalcolm; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC GSoC 2021 - Static analyzer project 2021-01-14 5:15 GCC GSoC 2021 - Static analyzer project Adharsh Kamath @ 2021-01-18 20:41 ` David Malcolm 2021-01-22 15:16 ` Adharsh Kamath 0 siblings, 1 reply; 7+ messages in thread From: David Malcolm @ 2021-01-18 20:41 UTC (permalink / raw) To: Adharsh Kamath; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC GSoC 2021 - Static analyzer project 2021-01-18 20:41 ` David Malcolm @ 2021-01-22 15:16 ` Adharsh Kamath 2021-01-22 16:01 ` David Malcolm 0 siblings, 1 reply; 7+ messages in thread From: Adharsh Kamath @ 2021-01-22 15:16 UTC (permalink / raw) To: David Malcolm; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC GSoC 2021 - Static analyzer project 2021-01-22 15:16 ` Adharsh Kamath @ 2021-01-22 16:01 ` David Malcolm 2021-01-23 9:04 ` Adharsh Kamath 2021-02-11 17:05 ` Adharsh Kamath 0 siblings, 2 replies; 7+ messages in thread From: David Malcolm @ 2021-01-22 16:01 UTC (permalink / raw) To: Adharsh Kamath; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC GSoC 2021 - Static analyzer project 2021-01-22 16:01 ` David Malcolm @ 2021-01-23 9:04 ` Adharsh Kamath 2021-02-11 17:05 ` Adharsh Kamath 1 sibling, 0 replies; 7+ messages in thread From: Adharsh Kamath @ 2021-01-23 9:04 UTC (permalink / raw) To: David Malcolm; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC GSoC 2021 - Static analyzer project 2021-01-22 16:01 ` David Malcolm 2021-01-23 9:04 ` Adharsh Kamath @ 2021-02-11 17:05 ` Adharsh Kamath 2021-02-11 18:46 ` David Malcolm 1 sibling, 1 reply; 7+ messages in thread From: Adharsh Kamath @ 2021-02-11 17:05 UTC (permalink / raw) To: David Malcolm; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: GCC GSoC 2021 - Static analyzer project 2021-02-11 17:05 ` Adharsh Kamath @ 2021-02-11 18:46 ` David Malcolm 0 siblings, 0 replies; 7+ messages in thread From: David Malcolm @ 2021-02-11 18:46 UTC (permalink / raw) To: Adharsh Kamath; +Cc: gcc 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2021-02-11 18:46 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-01-14 5:15 GCC GSoC 2021 - Static analyzer project Adharsh Kamath 2021-01-18 20:41 ` David Malcolm 2021-01-22 15:16 ` Adharsh Kamath 2021-01-22 16:01 ` David Malcolm 2021-01-23 9:04 ` Adharsh Kamath 2021-02-11 17:05 ` Adharsh Kamath 2021-02-11 18:46 ` David Malcolm
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).