Skip to content

Conversation

@6eanut
Copy link
Contributor

@6eanut 6eanut commented Jan 6, 2026

Currently, syzkaller is unable to test the kvm code under the RISC-V
architecture (as can be seen in the link
https://storage.googleapis.com/syzbot-assets/5522f9eefd80/ci-qemu2-riscv64-8f0b4cce.html,
the coverage for arch/riscv/kvm is 0). The reason is that previously,
due to the fact that RISC-V was not yet mature and stable in the KVM
aspect, the two files sys/linux/dev_kvm.txt and sys/linux/dev_kvm.txt.const
did not have compatibility with RISC-V.

With the development of RISC-V, a large number of RISC-V KVM codes have been merged into
the mainline of Linux (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git).
In order to enable syzkaller to test this part of the code, I attempted to adapt this task
myself. My workflow might be somewhat inefficient or clumsy in some parts.
If any friends could offer suggestions or guidance, I would be extremely grateful.

  • Firstly, I cloned the mainline version to my local machine and used the.config file
    provided by syzbot (https://syzkaller.appspot.com/text?tag=KernelConfig&x=88cadb2aebdef7ea)
    to cross-compile a riscv64 Linux kernel.
  • Then, I used syz-extract to extract the corresponding const from riscv64 dev_kvm.txt and
    manually integrated it into the existing dev_kvm.txt and dev_kvm.txt.const.

Two additional points to note:

  • I have separately created two files, dev_kvm_riscv64.txt and dev_kvm_riscv64.txt.const.
    Although the current contents are not significantly different from dev_kvm_extra.txt, I plan
    to add some pseudo system calls/RISC-V-specific operations for riscv64 in the future. If any
    friends can offer suggestions in this regard, I would be very happy.
  • Currently, I have temporarily modified the executor/common_linux.h file to adapt to the
    default version of syz_kvm_setup_cpu (mainly for successful compilation). In the future,
    I plan to create common_kvm_riscv64.h to implement more content.

To test the adaptation effect, during the fuzz testing process, I restricted the use of only
some system calls related to kvm. The configuration file is as follows:

	"enable_syscalls": [
	"openat$kvm",
        "ioctl$KVM*",
        "mmap",
        "munmap",
        "close",
        "eventfd2",
        "dup",
        "dup3",
        "getpid",
        "gettid",
        "exit",
        "exit_group",
        "tgkill",
        "rt_sigreturn",
        "syz_execute_func"
    ]

After testing for 24 hours, it can be observed that the code coverage of RISC-V KVM is no
longer zero.

image

If there are any areas that were not done well, please feel free to bring them up. I am
more than willing to make improvements.

@6eanut
Copy link
Contributor Author

6eanut commented Jan 7, 2026

Hi,

I would like to share my current progress on enabling KVM fuzzing support
for the RISC-V architecture in syzkaller, and ask for feedback to ensure
the direction is correct.

Current work: syz_kvm_setup_cpu for RISC-V
I have started implementing syz_kvm_setup_cpu support for riscv64. The
current changes include:
New files:

  • sys/linux/dev_kvm_riscv64.txt
  • sys/linux/test/syz_kvm_setup_cpu_riscv64
  • executor/common_kvm_riscv64.h

The current implementation is intentionally minimal:

  • Allocate guest memory
  • Copy a small guest code blob into memory
  • Initialize the guest PC register

This is sufficient to reach basic KVM execution paths on RISC-V.

Current blocker: syzlang text type
During compilation, I found that ifuzz / syzlang currently does not
support text[riscv64]. The existing text type only supports:
x86_real, x86_16, x86_32, x86_64, arm64

Since syz_kvm_setup_cpu relies on embedding guest machine code, I am
considering extending syzlang with support for text[riscv64].

I would be very happy if there is any advice or help.

@ramosian-glider
Copy link
Member

Hi there,

This is a great first step!
Just note that syz_kvm_setup_cpu is conceptually incorrect, because it mixes both VM and VCPU setup, making it harder to create two VCPUs in the same VM.
Feel free to proceed with adding it, but for the future I suggest you look into porting SYZOS to RISC-V.
There is no documentation so far, but #5887 may be of help.

@6eanut
Copy link
Contributor Author

6eanut commented Jan 8, 2026

Just note that syz_kvm_setup_cpu is conceptually incorrect, because it mixes both VM and VCPU setup, making it harder to create two VCPUs in the same VM. Feel free to proceed with adding it, but for the future I suggest you look into porting SYZOS to RISC-V. There is no documentation so far, but #5887 may be of help.

@ramosian-glider

Thanks again for your feedback.

As a next step, I plan to first try porting syz_kvm_setup_cpu in order to familiarize myself with the implementation model of pseudo-syscalls. As you pointed out, it has some conceptual limitations, so SYZOS is the longer-term target where I expect to spend more effort.

I’ve watched your LPC talk on SYZOS and found it very insightful. I agree that SYZOS is a strong improvement for KVM fuzzing, and I really appreciate you sharing your experience and design ideas there.

Thanks for the guidance and suggestions.

@6eanut
Copy link
Contributor Author

6eanut commented Jan 8, 2026

Hi all,

I’d like to share a small progress update. I have now adapted syz_kvm_setup_cpu for riscv64 (see commit: 6eanut@bfd98d0).

To validate the implementation, I added a test seed sys/linux/test/syz_kvm_setup_cpu_riscv64 and tested it following the procedure described in the documentation: https://github.com/google/syzkaller/blob/master/docs/syscall_descriptions.md#testing-of-descriptions

Concretely, I ran: ./syz-execprog -debug -threaded=0 syz_kvm_setup_cpu_riscv64 inside a riscv64 QEMU. The observed return values of the involved syscalls match the expected behavior.
image

This set of changes also includes basic support for KVM_GET_ONE_REG on riscv64.
I plan to submit the PR related to syz_kvm_setup_cpu after this current PR is merged, so that the changes can be reviewed and integrated incrementally.

As always, any feedback or suggestions are very welcome.

@6eanut 6eanut requested a review from ramosian-glider January 9, 2026 03:41
@ramosian-glider
Copy link
Member

I think we're good to go. I rebased your patch, let's commit it once the checks pass.

@6eanut
Copy link
Contributor Author

6eanut commented Jan 9, 2026

Thank you for your review. I will be preparing to submit the second patch.

@ramosian-glider ramosian-glider added this pull request to the merge queue Jan 9, 2026
Merged via the queue into google:master with commit 7e36833 Jan 9, 2026
18 checks passed
@6eanut 6eanut deleted the kvm_riscv branch January 19, 2026 09:35
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

Successfully merging this pull request may close these issues.

2 participants