Implement VirtIO RNG device by shengwen-tw · Pull Request #70 · sysprog21/semu

shengwen-tw · 2025-01-26T10:39:48Z

Overview

This commit introduces the VirtIO entropy device (also know as virtio-rng in QEMU and the Linux kernel) to resolve the blocking issue of arc4random_buf() [1] caused by insufficient entropy of /dev/random.

According to the man page (man 7 random):

The kernel random-number generator relies on entropy gathered from device drivers and other sources of environmental noise to seed a cryptographically secure pseudorandom number generator (CSPRNG).

Interface Pool: /dev/random
Pool: Blocking pool
Blocking behavior: If entropy too low, blocks until there is enough entropy
Behavior when pool is not yet ready: Blocks until enough entropy gathered

Quaoted from https://en.wikipedia.org/wiki//dev/random

With Linux kernel 3.16 and newer, the kernel itself mixes data from hardware random number generators into /dev/random on a sliding scale based on the definable entropy estimation quality of the HWRNG. This means that no userspace daemon, such as rngd from rng-tools, is needed to do that job. With Linux kernel 3.17+, the VirtIO RNG was modified to have a default quality defined above 0, and as such, is currently the only HWRNG mixed into /dev/random by default.

[1] https://elixir.bootlin.com/glibc/glibc-2.36/source/stdlib/arc4random.c

Close #68.

Prerequisites

Enable CONFIG_OD in BusyBox

$ cd buildroot/output/build/busybox-1.36.1/
$ make menuconfig

Rebuild buildroot

$ cd buildroot/
$ make busybox-rebuild
$ make -j$(nproc)

Replace rootfs.cpio

$ cd semu
$ cp -f buildroot/output/images/rootfs.cpio ./

Test procedures

Launch semu:

cd semu/
make check

Check if virtio-rng is used

# cat /sys/class/misc/hw_random/rng_available
virtio_rng.0

# cat /sys/class/misc/hw_random/rng_current
virtio_rng.0

Read /dev/random with od command

Welcome to Buildroot
buildroot login: root
# od /dev/random
0000000 126370 025274 055514 014745 051051 073714 156246 140301
0000020 157561 167176 122602 015767 107243 120045 136313 176061
0000040 115122 170566 107766 011777 057377 105023 152157 147260
0000060 130220 064322 160762 057245 153463 141757 046574 122202
0000100 174113 136630 120230 143307 073562 077302 017507 073016
0000120 062537 012454 100047 114555 140204 040440 172507 075066
0000140 040442 073115 161077 100450 037510 166327 163375 133510
0000160 176100 103667 010651 077154 077252 122605 046415 067073
0000200 042206 016216 101214 106563 161454 053741 016273 031322
0000220 166247 017356 066413 041563 124027 031751 054160 122432
...

Without virtio-rng, the od command will just hang due to the aforementioned issue.

ChinYikMing · 2025-01-27T00:29:35Z

Can you upload the newly built rootfs.cpio here for quick testing? Thanks!

shengwen-tw · 2025-01-27T06:08:52Z

Can you upload the newly built rootfs.cpio here for quick testing? Thanks!

You could try this: rootfs.cpio.zip

jserv

Improve the descriptions in git commit messages by quoting the man page for entropy. Also, always use Close #68 instead of Closed #68 to emphasize the intention.

ChinYikMing · 2025-01-28T06:01:24Z

I try on machine x86-64, compiled with gcc 12.3.0.

Procedure:

$ make check
login with root
# od /dev/random

Result:

...

[    3.884043] Run /init as init process
Starting syslogd: OK
Starting klogd: OK
Running sysctl: OK
Starting network: OK

Welcome to Buildroot
buildroot login: root 
# od /dev/random

Nothing is output (blocked), is it normal? I think the /dev/random should not be blocked?

shengwen-tw · 2025-01-29T07:36:02Z

I try on machine x86-64, compiled with gcc 12.3.0.

Procedure:

$ make check

login with root

# od /dev/random

Result:
...

[    3.884043] Run /init as init process
Starting syslogd: OK
Starting klogd: OK
Running sysctl: OK
Starting network: OK

Welcome to Buildroot
buildroot login: root 
# od /dev/random
Nothing is output (blocked), is it normal? I think the /dev/random should not be blocked?

It should not be blocked, could you check the following commands?

# cat /sys/class/misc/hw_random/rng_available
virtio_rng.0

# cat /sys/class/misc/hw_random/rng_current
virtio_rng.0

jserv · 2025-01-29T12:23:49Z

virtio-rng.c

+
+void virtio_rng_init(void)
+{
+    rng_fd = open("/dev/urandom", O_RDONLY);


/dev/random is probably going to be sufficient. What are the considerations to use /dev/urandom?

I used /dev/urandom because it does not block. However, this concern may not arise on the host, and adopting /dev/random is indeed more secure.

This commit introduces the VirtIO entropy device (also know as virtio-rng in QEMU and the Linux kernel) to resolve the blocking issue of arc4random_buf() [1] caused by insufficient entropy of /dev/random. According to the man page (`man 7 random`): The kernel random-number generator relies on entropy gathered from device drivers and other sources of environmental noise to seed a cryptographically secure pseudorandom number generator (CSPRNG). Interface Pool: /dev/random Pool: Blocking pool Blocking behavior: If entropy too low, blocks until there is enough entropy Behavior when pool is not yet ready: Blocks until enough entropy gathered Quaoted from https://en.wikipedia.org/wiki//dev/random With Linux kernel 3.16 and newer, the kernel itself mixes data from hardware random number generators into /dev/random on a sliding scale based on the definable entropy estimation quality of the HWRNG. This means that no userspace daemon, such as rngd from rng-tools, is needed to do that job. With Linux kernel 3.17+, the VirtIO RNG was modified to have a default quality defined above 0, and as such, is currently the only HWRNG mixed into /dev/random by default. [1] https://elixir.bootlin.com/glibc/glibc-2.36/source/stdlib/arc4random.c Close sysprog21#68.

ChinYikMing · 2025-01-29T14:30:03Z

I try on machine x86-64, compiled with gcc 12.3.0.
Procedure:

$ make check

login with root

# od /dev/random

Result:
...

[    3.884043] Run /init as init process
Starting syslogd: OK
Starting klogd: OK
Running sysctl: OK
Starting network: OK

Welcome to Buildroot
buildroot login: root 
# od /dev/random
Nothing is output (blocked), is it normal? I think the /dev/random should not be blocked?
It should not be blocked, could you check the following commands?
# cat /sys/class/misc/hw_random/rng_available
virtio_rng.0
# cat /sys/class/misc/hw_random/rng_current
virtio_rng.0

I get the following output:

# cat /sys/class/misc/hw_random/rng_available
cat: can't open '/sys/class/misc/hw_random/rng_available': No such file or directory

I noticed that the Linux kernel needs to enable the virtio-rng driver to facilitate communication in this scenario (enabled in the proposed changes of Linux configuration). Could you also upload the virtio-rng enabled Linux kernel image along with the rootfs.cpio?

shengwen-tw · 2025-01-29T15:15:48Z

I noticed that the Linux kernel needs to enable the virtio-rng driver to facilitate communication in this scenario (enabled in the proposed changes of Linux configuration). Could you also upload the virtio-rng enabled Linux kernel image along with the rootfs.cpio?

Here you go: Image.zip

ChinYikMing · 2025-01-31T07:00:42Z

Using newly built Linux kernel, the od /dev/random has no more blocking.

ChinYikMing · 2025-01-31T07:08:15Z

BTW, I used the newly built rootfs.cpio within rv32emu which does not implement the VirtIO RNG device and it does not block the /dev/random by running od /dev/random. @shengwen-tw Do you have any idea with this?

ChinYikMing · 2025-01-31T07:11:21Z

virtio-rng.c

+    /* Write entropy buffer */
+    void *entropy_buf =
+        (void *) ((uintptr_t) vrng->ram + (uintptr_t) vq_desc.addr);
+    ssize_t total = read(rng_fd, entropy_buf, vq_desc.len);


read could fail. Please handle the return value.

According to man 4 random:

When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

Calling read() function on /dev/random can only return -1 (i.e., failed) if O_NONBLOCK flag is set when opening the device. Specifically:

If open(2) is called for /dev/random with the O_NONBLOCK flag, a subsequent read(2) will not block if the requested number of bytes is not available. Instead, the available bytes are returned. If no byte is available, read(2) will return -1 and errno will be set to EAGAIN.

shengwen-tw · 2025-01-31T08:27:06Z

BTW, I used the newly built rootfs.cpio within rv32emu which does not implement the VirtIO RNG device and it does not block the /dev/random by running od /dev/random. @shengwen-tw Do you have any idea with this?

Entropy collection can be influenced by the speed of the hardware or the emulated environment.
I believe that rv32emu is currently fast enough to prevent blocking. However, it is always nice to have entropy supplied by the host.

jserv · 2025-02-01T08:10:04Z

Thank @shengwen-tw for contributing!

linux.config: Enable hardware random number generator with VirtIO

e25b108

shengwen-tw requested a review from jserv January 26, 2025 10:39

shengwen-tw added the enhancement New feature or request label Jan 26, 2025

shengwen-tw mentioned this pull request Jan 26, 2025

VirtIO RNG and unexpected behavior of arc4random_buf() standard function of C #68

Closed

shengwen-tw requested a review from ChinYikMing January 27, 2025 07:07

jserv requested changes Jan 27, 2025

View reviewed changes

shengwen-tw force-pushed the virtio-rng branch 5 times, most recently from b5c6511 to c2f267d Compare January 29, 2025 08:12

jserv reviewed Jan 29, 2025

View reviewed changes

shengwen-tw force-pushed the virtio-rng branch from c2f267d to 9b3b4aa Compare January 29, 2025 12:58

ChinYikMing reviewed Jan 31, 2025

View reviewed changes

jserv merged commit 50fbf07 into sysprog21:master Feb 1, 2025
3 checks passed

shengwen-tw deleted the virtio-rng branch June 14, 2025 13:21

shengwen-tw mentioned this pull request Jul 3, 2025

Support virtio-fs #88

Merged

Conversation

shengwen-tw commented Jan 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Overview

Prerequisites

Test procedures

Uh oh!

ChinYikMing commented Jan 27, 2025

Uh oh!

shengwen-tw commented Jan 27, 2025

Uh oh!

jserv left a comment

Choose a reason for hiding this comment

Uh oh!

ChinYikMing commented Jan 28, 2025

Uh oh!

shengwen-tw commented Jan 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jserv Jan 29, 2025

Choose a reason for hiding this comment

Uh oh!

shengwen-tw Jan 29, 2025

Choose a reason for hiding this comment

Uh oh!

ChinYikMing commented Jan 29, 2025

Uh oh!

shengwen-tw commented Jan 29, 2025

Uh oh!

ChinYikMing commented Jan 31, 2025

Uh oh!

ChinYikMing commented Jan 31, 2025

Uh oh!

ChinYikMing Jan 31, 2025

Choose a reason for hiding this comment

Uh oh!

shengwen-tw Jan 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

shengwen-tw commented Jan 31, 2025

Uh oh!

Uh oh!

jserv commented Feb 1, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

shengwen-tw commented Jan 26, 2025 •

edited

Loading

shengwen-tw commented Jan 29, 2025 •

edited

Loading

shengwen-tw Jan 31, 2025 •

edited

Loading