[Help Welcome] KVM Development - staying the course

KVM
575

If it would be really the same, then /dev/random would be a symlink to /dev/urandom or vice versa.

As already quoted above, the updated manpage it’s still saying:

/dev/random is suitable for applications that need high quality randomness, and can afford indeterminate delays.

And it is up to the kernel to maintain this manpage.

Also also it’s possible to look up the source code on how /dev/random versus /dev/urandom is actually implemented in the Linux kernel. Documented just now:

Code Comparison - /dev/random vs. /dev/urandom

Code from end of July 2024.

It’s trivial to see (probably even for a non-programmer) that there are differences between /dev/random versus /dev/urandom.

576

Yes

Dunno. I would need to research attacks in the wild that can do this.

Yes There has been a setting to rate limit the entropy available to the guest. I made use of it in the past and you may be able to access it in the git history log.

Moreover, the quotes from the /dev/random page you’re quoting don’t really give the impression of the improvement I’ve been reading elsewhere. The whole point of the work on the crypto subsystem was to make both of them have functional and security parity and to remove the need for performance limits set by /dev/random.

1 Like
577

Then the correct solution would be /dev/random + rate limits.

All the write-ups are smoke and mirrors, secondary. The source code is the primary source of truth and clearly shows different code paths for /dev/random and /dev/urandom.

578

QEMU feature request:

579

Turns out I researched and documented this previously: Dev/KVM - Whonix

I had it in the guest settings at one point but renaming and moving the packages obliterated the git history.

1 Like
580

Was initially configured here:

Questions:

  • What git commit changed from random to urandom?
  • What git commit remove the rate limit?

The git commit is not so important as long as the rationale back then is known. Because I think it would be good to re-add the rate limit, which I am about to do.

581

My rationale for removing /dev/random + rate limit is that it was under the assumption that Linux upstream fixed the problems of safely seeding urandom on startup and its non-blocking nature made entropy plentiful and readily available that I didn’t think could be practically exhausted unlike the blocking /dev/random interface.

Also I noticed new VMs configs had switched out random for urandom.

1 Like
582

Done.

Untested.

Could you test this please? @nurmagoz

What is the expected result: There should not be any noticeable differences. At worst the XML would be invalid and the VMs no longer starting. Unlikely but better to test this now than noticing it after the next release.

1 Like
583

Yes as you mentioned, no noticeable differences.

How the test was done:

user@host:~$ sudo virsh edit Whonix-Gateway

At the bottom of the file add <rate bytes='1024' period='1000'/> similar to:

<rng model='virtio'>
      <rate bytes='1024' period='1000'/>
      <backend model='random'>/dev/random</backend>
      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
    </rng>
  </devices>
</domain>

Then start the VM. (repeat the same thing with Whonix-Workstation)

1 Like
584

Perfect!

1 Like
585

A post was split to a new topic: can’t connect to tor relay on whonix-gateway.

586
1 Like
587
588
589

I have sorted, added newlines within the XML files according to category (such as CPU, RAM, blkiotune, OK) to make the XML files more readable.

Comments in the XML files are (nowadays?) actually possible.

<!-- Graphics settings -->

Full example

<!-- Graphics settings -->
<graphics type='spice' autoport='yes'>
  <listen type='none'/>
  <clipboard copypaste='no'/>
  <filetransfer enable='no'/>
  <gl enable='no'/>
</graphics>

These comments might be lost after importing (virsh define) the VMs, which is non-ideal. However, even if we could just comment better the XML files that would be helpful.

Since we have 4 VM XM files (which are Kicksecure.xml Whonix-Gateway.xml Whonix-Workstation.xml Whonix-Custom-Workstation.xml), I was wondering if we should either copy/paste the same comments that apply to all VM’s XML files or limit the comments to 1 file (such as Kicksecure.xml).

Another option would be to have a XML file template and generate the other XML files based on it. But that could be more difficult to understand. So not using that.

What kind of comments need adding? For instance, consider this setting:

<memballoon model='none'/>

Why is memory ballooning disabled? Seems to be a nice feature that a VM only uses as much RAM as it needs and gives unneeded RAM back to the host. The reason is documented here: Dev/KVM, memory balloon

What I would propose is to add a comment such as:

<!-- https://www.whonix.org/wiki/Dev/KVM#memory_balloon -->
<memballoon model='none'/>
590

/dev/urandom and /dev/random is the same thing these days, so a bit pointless on non ancient kernels.

Same conclusion.

591

I would guess it’s an opinion based on secondary write-ups, not based on reading the actual kernel source code.

We’ll comment there as well to point that out.

Before trying to make the point by showing to anyone who writes a short comment, please try reading the actual kernel source code. There’s no need to to really understand what’s happening there but it’s obvious that it’s not the same thing.

Falling short of reading the source code, try looking at random.c kernel source code to just read the source code comments might suffice as well.

  • Reading from /dev/random has the same functionality as calling
  • getrandom(2) with flags=0.
  • Reading from /dev/urandom has the same functionality as calling
  • getrandom(2) with flags=GRND_INSECURE. Because it does not block
  • waiting for the RNG to be ready, it should not be used.

Pretty obvious that this is not the same thing.

1 Like