nyx-fuzz / qemu-nyx Goto Github PK

I think the vm_start() call in Nyx snapshot loading is redundant and should be removed:

The function is only called from vl.c, which performs vm_start() later on:

When qemu -S is used, the "autostart" is false and vm_start() is normally not called until gdb connect. But due to the extra vm_start(), we cannot currently launch Qemu from a snapshot AND wait for gdb.

Simply removing the line 350 seems to work fine. Opinions?

For non-interactive / production use, I think Qemu should simply exit on fatal errors. Waiting for gdb attach often results in hanging Qemu instances and it not helpful outside of actually debugging Qemu.

I think we can adjust the assert/abort handlers to wait for gdb only in debug mode, and otherwise simply exit.

Hi,
I found the:
QEMU_CONFIGURE="./configure --target-list=x86_64-softmmu --disable-gtk --disable-docs --enable-gtk --disable-werror --disable-capstone --disable-libssh --disable-tools"
in the compile_qemu_nyx.sh line 55.

So, will nyx use the gtk UI of the qemu? Can I set it directly to "-disable-gtk"?

Thanks.

When using the pre_path argument of the -fast_vm_reload option, it is currently not possible to use a relative path.

Latest version of QEMU-Nyx works, but doesn't allow to properly install system.
Before building QEMU-Nyx i followed all the installation instructions from here https://github.com/nyx-fuzz/KVM-Nyx, then installed pkg-config, flex and bison via apt. After that i cloned the QEMU-Nyx repository, executed "./compile_qemu_nyx.sh lto" and after the building was done i added qemu-system-x86_64 to PATH (for conviniece)

The problem:
After trying to install freebsd from https://github.com/RUB-SysSec/Nyx/tree/main/Targets/bhyve/VM i am getting error during the VM installation process. While installing on clean qemu-kvm (apt install qemu-kvm) i don't get any errors with the same parameters. Even when i managed to install the VM, i am returning back to the installer after reboot.

Lets add proper checks for common mmap/malloc failure modes such as #27 or this (from discord):

qemu-system-x86_64: /home/user/kAFL/kafl/qemu/nyx/snapshot/memory/shadow_memory.c:288: shadow_memory_init_from_snapshot: Assertion `mmap(host_addr, self->ram_regions[i].size, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_FIXED, self->snapshot_ptr_fd, self->ram_regions[i].offset) != MAP_FAILED' failed.

Printing errno followed by exit() is probably more useful than assert().

I am using KVM-Nyx on Ubuntu 20.04 with a processor that supports intel-pt.
I was following the tutorial listed here: https://github.com/Kharos102/kAFL/blob/master/docs/windows_tutorial.md
Whenever I run this command,

/kAFL/qemu-5.0.0/x86_64-softmmu/qemu-system-x86_64 -machine q35 -enable-kvm -m 1024 -hda ./windows.qcow2 -cdrom ./windows.iso

the qemu binary crashes with the following error

qemu-system-x86_64: /home/blank/Downloads/kAFL/kafl/qemu/nyx/pt.c:326: pt_pre_kvm_run: Assertion `cpu->pt_mmap != (void*)0xFFFFFFFFFFFFFFFF' failed.

How should I fix this?

Latest QEMU is 7.1 and there were immense improvements in many different areas since 4.2.0

• https://wiki.qemu.org/ChangeLog/7.1
• https://wiki.qemu.org/ChangeLog/7.0
• https://wiki.qemu.org/ChangeLog/6.2
• https://wiki.qemu.org/ChangeLog/6.1
• https://wiki.qemu.org/ChangeLog/6.0
• https://wiki.qemu.org/ChangeLog/5.2
• https://wiki.qemu.org/ChangeLog/5.1
• https://wiki.qemu.org/ChangeLog/5.0

Hi. I have been working on rebasing QEMU-Nyx to a more recent version of QEMU. I’ve made some good progress, and I think it’s almost working, though at the moment it’s failing during snapshot reload. After a panic/crash during fuzzing, sometimes just not resuming the target, but I’ve also had a few segfaults. It seems to be happening in fdl_fast_reload while the saved fields are being copied from self->copy back to self->ptr.

I’m still trying to track down the root cause, but it’s slow going because I don’t fully understand the snapshot process. Working theory is maybe some device or field temporarily exists at snapshot creation time but then not at reload time (so those pointers to fields are no longer valid)?

As an aside, my code could use some tidying as I've been focused on getting the functionality working, and I've temporarily disabled some unit tests until I can fix some build issues associated with the move to Meson.

Any pointers would be welcome, as would feedback on the rebase since my goal would be to submit a PR eventually.

Fork with the in-progress rebase is at
https://github.com/SpencerCBrown/QEMU-Nyx/tree/kafl-qemu-8.1.0

You call synchronization_disable_pt => pt_disable in handle_hypercall_kafl_release but never enable it back inside handle_hypercall_kafl_next_payload.

I think this only triggers if more than one IP region is used..

I observed some parse error when adding Qemu options after -fast_vm_reload. Not sure if this is expected behavior or a bug in how -fast_vm_reload is parsed? I did not see any obvious issue in the code..

Adding -device before -fast-vm-reload works fine:
qemu-system-x86_64 -enable-kvm -machine kAFL64-v1 -cpu kAFL64-Hypervisor-v1,+vmx -drive if=virtio,format=raw,file=/tmp/disk.qcow2 -fast_vm_reload path=/dev/shm/kafl/snapshot/,load=off

Appending afterwards fails in cmdline parser:
qemu-system-x86_64 -enable-kvm -machine kAFL64-v1 -cpu kAFL64-Hypervisor-v1,+vmx -fast_vm_reload path=/dev/shm/kafl/snapshot/,load=off -drive if=virtio,format=raw,file=/tmp/disk.qcow2
qemu-system-x86_64: Invalid parameter 'if'

leftover from dell/kvm fallback?

Calling HOST_CONFIG or AGENT_CONFIG multiple times is currently forbidden. It may be good to warn or log the event but is there any issue with calling them multiple times, before NEXT_PAYLOAD?

In principle, hget / hpush tools should check HOST_CONFIG => magic/version every time, no?

Hello ！ thank you very much for your work. It's amaizing. When I reproduced, I ran into some problems. Once I've done the ./compile_qemu_nyx.sh lto build, how do I proceed with the fuzz test in qemu next ?

looking forward your reply

@il-steffen The duplicate aliases are indeed incorrect. The expected behavior would be that the kAFL64 PC type refers to the PIIX machine type. I'll take care of that as soon as possible.

As for the warning, I guess this is actually expected behavior. The kAFL64-Hypervisor-v1 CPU type is used exclusively for PT mode, but when a non-KVM PT kernel is detected, the CPU type is automatically switched to v2 instead and the warning is thrown. We can fix that by simply changing the verbose mode of this warning so that the warning is only shown in debug mode.

Originally posted by @schumilo in #47 (comment)

Hello,
I am facing a new problem when trying to create a windows 10 VM using qemu-nyx.
My command to start the vm is as follows:

./kAFL/kafl/qemu/x86_64-softmmu/qemu-system-x86_64 -machine q35 -enable-kvm -m 4096 -hda ./windows.qcow2 -cdrom ./windows.iso -boot d

When the setup reaches to the page to select the partition, Windows says that it is unable to install the OS to the disk. Looking into the setup logs and output of diskpart, I can see that whenever Windows tries to write or modify the disk, it gives an error saying that this drive is write-protected.
How can I fix this issue?

Note: Whenever I use normal qemu with the exact same CLI arguments and disk, Windows is able to install to the disk with ease. This shows that the problem may lie in the nyx version of qemu

cc @c01db33f

I'm still getting the "page duplicate found" error after applying the fix in #7. The issue pops up randomly every couple fuzzer launches but it feels like it may have gotten less severe?