Kernel Dump Regression Testing

• Student: Ritika Gupta (ritikagupta1998@gmail.com)
• Mentor: Mark Johnston (markj@)

Testing is an integral and important part of any software development cycle, open or closed. Given a fully automated test system, we can run a broad variety of tests with high frequency, and find problems soon after they are introduced. Kernel Crash Dumping mechanism that allows us to save the contents of the system’s memory for later analysis. The FreeBSD core dump facility preserves a copy of the contents of system memory to a special disk partition at the time of a fatal error for later debugging. This copy or “dump” can be a machine-readable form of the complete contents of system memory or just the set of kernel pages that are active at the time of the crash. The state can be recovered by saving it to a file under /var/crash. Kernel core dumps allow us to examine the state of the kernel after a kernel panic or hang. Currently, there is no automated test suite in FreeBSD to verify if all the code paths work. The aim of the project is to create a framework for recovering and testing those kernel dumps for a different set of configuration variables or code paths while logging every test case separately in a log file and later analyzing which code paths failed.

(Details as to how you intend to approach the problem, if applicable. May include ideas as to how to break the problem down into smaller parts, or notes on research you need to do before settling on your final approach to solving the problem)

Deliverables for first evaluation: A module written in Python which would be able to take Hardware/VM configuration variables and Kernel Dump configuration variables as input and, Generate VM configuration Launch the VM Configure kernel dumper Debugging the kernel dump and verifying whether the dump is valid

Deliverables for second evaluation: A comprehensive and automated test-suite that will be able to test the kernel dumps generated for a combination of configuration variables, both locally and over a network. Configure a netdump server on the host machine or a second VM and start dumping over a network Identify the set of test cases to be tested Deliverables for last evaluation: Carry out rigorous testing for every combination of the variables and log out the failures on a separate file. Analyze the code paths which failed If time permits, Python gdb script will be written that does a bunch of checks and verifies that it runs successfully.

(List of features you plan to implement)

(5-10 milestones, with dates, indicating when you hope or expect to be able to complete features. This section is mandatory. Please negotiate these with your mentor to make sure you're not under- or over-estimating the amount of work to be done. Please also make sure the following four dates are included within your milestones)

• May 14th: Start of coding
  • Get ready with my dedicated hardware for the project, interact with the FreeBSD community and try to get valuable inputs from the community.

• May 21st: Week 2
  • Start working on the module and expect it to be utilizing bhyve for hosting a VM with necessary specifications
  • Start using pexpect to interact with the VM’s console and providing the necessary values for the configuration variables

• June 11th - June 15th: Mid-term Evaluations #1
• July 9th - July 13th: Mid-term Evaluations #2
• August 6th: End of coding (soft)
  • You may wish to use this time to complete documentation etc
• August 14th: End of coding (hard)

(List of steps you plan to use to test your work, as discussed with your mentor)

https://github.com/ritika98/freebsd

(A place to make notes that will be useful to others looking at your code. You probably don't need to put anything here on day one)

(Links to any external resources, work, research etc which may be useful to you or to anybody wanting to understand your work)