Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to reuse ram.qcow2 in parallel fuzzing mode. #15

Closed
Bl1nnnk opened this issue Aug 26, 2020 · 7 comments
Closed

Failed to reuse ram.qcow2 in parallel fuzzing mode. #15

Bl1nnnk opened this issue Aug 26, 2020 · 7 comments

Comments

@Bl1nnnk
Copy link

Bl1nnnk commented Aug 26, 2020

The snapshot file "ram.qcow2" is used concurrently by the instances in parallel fuzzing mode. But maybe modern QEMU introduced a new feature "file lock"?

The error log looks like:

qemu-system-x86_64: -hdb /home/jungu/kafl/snapshots/win8_x64/ram.qcow2: Failed to get "write" lock

Does this error take place in your environment?

@il-steffen
Copy link
Collaborator

Hi! I have not seen this but I also barely use the VM-style launching.
Have you tried with qemu-4.2? Just enable it in install.sh and point your kafl.ini to it.

@moehw
Copy link

moehw commented Aug 30, 2020

Hello! I have the same problem and this error appears on both qemu-5.0 and qemu-4.2.
I solved it just to take advantage of parallel fuzzing by creating one more ram.qcow2. I rewrote qemu.py to use vm_ram exactly the same as vm_dir (ram_<id>.qcow2 and overlay_<id>.qcow2). Is there a prettier way?

@il-steffen
Copy link
Collaborator

It seems this is a feature and there are half-documented options to get around it.
https://bugs.launchpad.net/juju/+bug/1816170/comments/8

I'm not sure from the description if you just need to supply -U/--force-share to qemu-img when creating the backing image, or supply shared-rw (renamed to force-share=on?) on qemu cmdline, or both. Also it looks like force-share=on may only work for -blockdev, which is the modern version of -drive..

@Bl1nnnk
Copy link
Author

Bl1nnnk commented Aug 31, 2020

I also use the method that @nola-milkin mentioned, it's useful.

@il-steffen
Copy link
Collaborator

The separate vm_ram option was removed some time ago when testing on Windows. Do we know if the above approach also allows using multiple cores for Windows VM fuzzing? Cc @vient

@vient
Copy link
Contributor

vient commented Mar 11, 2021

Do you mean if we can make several RAM copies and use them for Windows fuzzing instead of removing vm_ram option? For that answer is yes, this was the first thing I tried. The reason why I went to remove vm_ram instead is because I don't understand it's meaning: RAM still needs to be copied as well as overlay, we might just combine them in one file then.

@il-steffen
Copy link
Collaborator

Thanks. I just also confirmed that the Linux VM use case works with just the overlay_N file. Will update the guide accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants