update README #80
update README #80
Conversation
il-steffen
commented
Jun 30, 2022
il-steffen
commented
- notice about code for research
- notice about Intel PT and host kernel requirement
- simplify texts for local/remote install
- update how to activate environment
- notice about code for research - notice about Intel PT and host kernel requirement - simplify texts for local/remote install - update how to activate environment
… that remote deployment assumes passwordless setup
|
squash me.. |
README.md
Outdated
| - The setup requires a Gen-6 or newer Intel CPU (for Intel PT) and sufficient | ||
| RAM to run several VMs at once. | ||
| - A modifed Linux host kernel is required for VM-based snapshot fuzzing with | ||
| Intel PT coverage feedback. This setup does not run inside a VM or container! |
There was a problem hiding this comment.
Why the notice that it doesn't run inside a VM or container ?
Did you wanted to say:
- "this current setup doesn't run in a VM or container"
- "this kAFL setup cannot run in a VM or container"
because the latter, especially the container part is true, we can run a Dockerized kAFL.
There was a problem hiding this comment.
Purpose is to warn that we (currently) assume physical host access to modify the kernel. Yes we can say current / supported setup.
There was a problem hiding this comment.
you don't need physical host access to update a kernel.
I mean, kAFL could run in a nested virtualization setup for example (?), for testing purpose.
For example, can I develop a Vagrant based solution for my kAFL developer workflow ?
Because if that's possible, then this sentence is ambiguous :)
There was a problem hiding this comment.
Nested setup has been done with Qemu-Nyx/KVM-Nyx but these modes are completely untested, at least from my perspective. The Nyx hypervisor fuzzing projects use this, together with a modified hypercube as the agent, but this was not working/tested in the latest upstream repos and I don't know what is the status.
So while not impossible, I think we need to make very clear that we currently assume this for our make deploy flow. I'll propose a change.
There was a problem hiding this comment.
Okay, thanks for the clarification regardig nested virt support.
I can propose this:
Note: This setup requires a bare-metal configuration, since nested virtualization is not support by kAFL at this point.
README.md
Outdated
|
|
||
| The userspace installation and fuzzing workflow has been tested for recent | ||
| Ubuntu (>=20.04) and Debian (>=bullseye). The base installation is captured | ||
| as an Ansible workflow which you can bootstrap using Python: |
There was a problem hiding this comment.
Does the user need to know about the underlying deployment / installation tools ?
The only requirement it to have Python3 and the capacity to create virtual environments.
There was a problem hiding this comment.
I found it misleading to say python3 is the only requirement, so I rewrote to explain we have a well-defined install flow "based on Python". Other suggestions?
We're actually pulling a lot of things as part of deployment: apt install, kernel install, grub config change, KVM group mod, kvm module options, and we don't offer uninstall. It may actually be good to document this somehow so the user has a chance to revert/debug.
There was a problem hiding this comment.
OK, I understand the need to explain what's about to happen when the user call make deploy.
I would rephrase like this:
The userspace installation and fuzzing workflow has been tested for recent
Ubuntu (>=20.04) and Debian (>=bullseye). The base installation is managed
as an Ansible playbook which you can bootstrap with the following commands.
- playbook is the right terminology for Ansible (not workflow)
- I would avoir mentionning
using Pythonbecause that magic stuff is done by the Makefile recipe. The user just callsmake deployand that's it. He doesn't use Python in any way (not directly)
We can document what changes are made to the system, so the user has a better understanding of how to revert it into a previous state.
README.md
Outdated
|
|
||
| The userspace installation and fuzzing workflow has been tested for recent | ||
| Ubuntu (>=20.04) and Debian (>=bullseye). The base installation is captured | ||
| as an Ansible workflow which you can bootstrap using Python: |
There was a problem hiding this comment.
OK, I understand the need to explain what's about to happen when the user call make deploy.
I would rephrase like this:
The userspace installation and fuzzing workflow has been tested for recent
Ubuntu (>=20.04) and Debian (>=bullseye). The base installation is managed
as an Ansible playbook which you can bootstrap with the following commands.
- playbook is the right terminology for Ansible (not workflow)
- I would avoir mentionning
using Pythonbecause that magic stuff is done by the Makefile recipe. The user just callsmake deployand that's it. He doesn't use Python in any way (not directly)
We can document what changes are made to the system, so the user has a better understanding of how to revert it into a previous state.
README.md
Outdated
| - The setup requires a Gen-6 or newer Intel CPU (for Intel PT) and sufficient | ||
| RAM to run several VMs at once. | ||
| - A modifed Linux host kernel is required for VM-based snapshot fuzzing with | ||
| Intel PT coverage feedback. This setup does not run inside a VM or container! |
There was a problem hiding this comment.
Okay, thanks for the clarification regardig nested virt support.
I can propose this:
Note: This setup requires a bare-metal configuration, since nested virtualization is not support by kAFL at this point.
- notice about code for research - notice about Intel PT and host kernel requirement - simplify texts for local/remote install - update how to activate environment
