Setup CI Pipeline on Github

[zakuArbor]

Purpose

Setup a CI pipeline for Github and Jenkins. The goal is to integrate CI DevOps practice both for the project and for personal learning. This is to include code coverage, static analysis, and lint. May setup a zenhub board to better manage issues and explore other devOps tools offered on Github and Jenkins to improve workflow.

Tasks/Goals

• Ensure Github Actions can Build Ubuntu Builds
• Setup Jenkins Server on Raspberry Pi
• Setup Security Code Analysis
• Setup Ubuntu node on Jenkins (perhaps change to Fedora)
• Setup static analyzers
• Setup doxygen workflow generation and deployment
• Setup linter
  • See if splint is a good idea to add to workflow
• Setup fuzzer (i.e. afl)
• (optional) setup cppcheck

Summary

To fill out once the issue is to be closed. Give a short summary of the changes you made to implement or fix an issue

• Github action workflow to build code has been completed
• Github action workflow static analysis has been completed (using CodeQL)
• Github action workflow to generate oxygen and deploy on github pages has been completed

[zakuArbor]

Side Notes (for future references)

fuzzer: afl

Installation:

1. download tarball
2. make
3. sudo make install
4. create afl_in and afl_out directories
5. add sample test cases into afl_in

Running:

Problem 1:

$ afl-fuzz -i afl_in -o afl_out -- ./fuzzgoat @@
...
[-] Hmm, your system is configured to send core dump notifications to an
    external utility. This will cause issues: there will be an extended delay
    between stumbling upon a crash and having this information relayed to the
    fuzzer via the standard waitpid() API.

    To avoid having crashes misinterpreted as timeouts, please log in as root
    and temporarily modify /proc/sys/kernel/core_pattern, like so:

    echo core >/proc/sys/kernel/core_pattern

Resolution 1: export AFL_I_DONT_CARE_ABOUT_MISSING_CRASHES=1

Problem 2:

[-] Whoops, your system uses on-demand CPU frequency scaling, adjusted
    between 390 and 4003 MHz. Unfortunately, the scaling algorithm in the
    kernel is imperfect and can miss the short-lived processes spawned by
    afl-fuzz. To keep things moving, run these commands as root:

    cd /sys/devices/system/cpu
    echo performance | tee cpu*/cpufreq/scaling_governor

    You can later go back to the original state by replacing 'performance' with
    'ondemand'. If you don't want to change the settings, set AFL_SKIP_CPUFREQ
    to make afl-fuzz skip this check - but expect some performance drop.

Resolution 2: export AFL_SKIP_CPUFREQ=1

consider: https://github.com/google/AFL/blob/master/docs/notes_for_asan.txt
Apparently, using asan with fuzzer is not a good idea. So need to disable asan when using fuzzer probably.

Testing Framework:

1. check

• reference: https://www.ccs.neu.edu/home/skotthe/classes/cs5600/fall/2015/labs/intro-check.html
• example: https://github.com/intel/cc-oci-runtime/tree/master/tests

2. cpputest

• https://www.amazon.ca/Test-Driven-Development-Embedded-C/dp/193435662X
• https://www.sparkpost.com/blog/getting-started-cpputest/

also take a look if this would be useful: (pam_wrapper) https://lwn.net/Articles/671094/

Todo:

• create unit test cases with asan enabled
• ensure NDEBUG is not set to have assert in production build
• create small programs to test major functions and provide it into the fuzzer

Future Reference: https://medium.com/@ayushpriya10/fuzzing-applications-with-american-fuzzy-lop-afl-54facc65d102