[Help Welcome] KVM Development - staying the course

[Patrick]

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.

[HulaHoop]

@Patrick

The threat model being, the VM running malware exhausting the host’s
/dev/random?

Yes

@Patrick

Is this possible nowadays?

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

@Patrick

Can virtio moderate 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.

[Patrick]

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

@HulaHoop

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.

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.

[Patrick]

QEMU feature request:

Isolated network between VMs not visible to the host (#2494) · Issues · QEMU...

[HulaHoop]

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.

[Patrick]

Was initially configured here:

Rate limit RNG

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.

[HulaHoop]

@Patrick

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.

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.

[Patrick]

@Patrick

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

Done.

rate limit RNG /dev/random

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.

[nurmagoz]

@Patrick

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.

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)

[Patrick]

Perfect!

[Patrick]

stop using unit='KiB' - use unit='MB' instead

libvirt-dist/usr/share/libvirt-dist/xml at master · Kicksecure/libvirt-dist · GitHub <memory dumpCore='off' unit='KiB'>2097152</memory> <currentMemory unit='KiB'>2097152</currentMemory> Why are we using such an unpopular unit of KiB? unit=‘KiB’ Maybe this is legacy from times where libvirt did not support any other, if that was the case? Unless there is a good reason against it… Could you please change the unit to MB for all XML configuration files? @nurmagoz <memory dumpCore='off'…

[Patrick]

newlines

[Patrick]

newlines

shuffle

[Patrick]

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'/>