mirror of
https://github.com/vanhoefm/fragattacks.git
synced 2024-11-25 08:48:31 -05:00
e339511007
If telnetd is installed and --telnet <port> is passed on the vm-run.sh command line, start a telnet server (directly connected to bash, no login) inside the VM(s) to be able to look into them when something is wrong. Use a user network in qemu with a single host forward from the specified port for this, listening only on 'localhost'. Please note that this provides unauthenticated access to the guest system from anything that can open a TCP connection on the host system. The guess system does have access to reading all files on the host that the user account running kvm has access to (and even write access if the default ROTAG ,readonly parameter is cleared). In other words, this option should not be used on any multiuser systems where kvm is run under user accounts that are not dedicated for testing purposes (i.e., do not have access to any files that should not be readable to everyone). This needs CONFIG_VIRTIO_NET=y in the guest kernel. For parallel-vm.py, the --telnet argument specifies the base port and each VM index (0, 1, ...) is added to it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| bisect-run.sh | ||
| build-codecov.sh | ||
| combine-codecov.sh | ||
| dbus.conf | ||
| example-vm-setup.txt | ||
| inside.sh | ||
| kernel-config | ||
| parallel-vm.py | ||
| process-codecov.sh | ||
| README | ||
| uevent.sh | ||
| vm-run.sh | ||
These scripts allow you to run the hwsim tests inside a KVM virtual machine. To set it up, first compile a kernel with the kernel-config file as the .config. You can adjust it as needed, the configuration is for a 64-bit x86 system and should be close to minimal. The architecture must be the same as your host since the host's filesystem is used. Install the required tools: at least 'kvm', if you want tracing trace-cmd, valgrind if you want, etc. Compile the hwsim tests as per the instructions given, you may have to install some extra development packages (e.g. binutils-dev for libbfd). Create a vm-config file and put the KERNELDIR option into it (see the vm-run.sh script). If you want valgrind, also increase the memory size. Now you can run the vm-run.sh script and it will execute the tests using your system's root filesystem (read-only) inside the VM. The options you give it are passed through to run-all.sh, see there. To speed up testing, it is possible to run multiple VMs concurrently and split the test cases between all the VMs. If the host system has enough memory and CPU resources, this can significantly speed up the full test cycle. For example, a 4 core system with 4 GB of RAM can easily run 8 parallel VMs (assuming valgrind is not used with its higher memory requirements). This can be run with: ./parallel-vm.py <number of VMs> [arguments..] -------------------------------------------------------------------------------- Code Coverage Analysis for user space code Code coverage for wpa_supplicant and hostapd can be generated from the test run with following command line: ./vm-run.sh --codecov [other arguments..] This builds a separate copies of wpa_supplicant and hostapd into a directory that is writable from the virtual machine to collect the gcov data. lcov is then used to prepare the reports at the end of the test run. Code Coverage Analysis for kernel code In order to do code coverage analysis, reconfigure the kernel to include CONFIG_GCOV_KERNEL=y CONFIG_GCOV_PROFILE_ALL=y Note that for gcc 4.7, kernel version 3.13-rc1 or higher is required. The scripts inside the VM will automatically copy the gcov data out of the VM into the logs directory. To post-process this data, you'll want to use lcov and run cd /tmp/hwsim-test-logs/<timestamp> lcov -b <path to kernel dir> -c -d gcov/ > gcov/data genhtml -o html/ gcov/data Then open html/index.html in your browser. Note that in this case you need to keep your build and source directories across the test run (otherwise, it's safe to only keep the kernel image.)