[Help Welcome] KVM Development - staying the course

KVM
301

Changes for Buster hosts:

  • RAM will be allocated as needed. Should make resource use more efficient.

  • Upon guest termination, all memory should be wiped this should be a nice anti-forensic feature against “warm” RAM attacks for guests that were running in live mode. Linux cleans RAM only when it is about to be resused by another process. This ensures no info from the guest RAM is floating around after guest is off.

  • Switched RNG to urandom where rate limiting is not critical because the interface doesn’t block (jitterentropy-rngd should be on the host for best results)

  • Only a line-out/speaker is attached to VMs microphone not available by default. Instructions will be added to reverse this for users who want VoIP.

EDIT:

  • Re-enabled pvspinlock for better vvcpu performance and reduced code-path use

  • Excluded Guest RAM contents from any memory dumps on hosts that have coredumps enabled in case libvirt crashes(Debian does not)

*https://github.com/Whonix/whonix-libvirt/pull/87/commits/704972ae4654fa635703101929f575176ce7f4af

*More security features on Buster by HulaHoopWhonix · Pull Request #88 · Kicksecure/libvirt-dist · GitHub

*More security features on Buster by HulaHoopWhonix · Pull Request #89 · Kicksecure/libvirt-dist · GitHub

*More security features on Buster by HulaHoopWhonix · Pull Request #90 · Kicksecure/libvirt-dist · GitHub

A new build will be available soon.

1 Like
302

This More security features on Buster by HulaHoopWhonix · Pull Request #87 · Kicksecure/libvirt-dist · GitHub i.e. setting from

   <backend model='random'>/dev/random</backend>

to

   <backend model='random'>/dev/urandom</backend>

has to be carefully considered.

Is this recommended / discussed somewhere?

What would happen in the guest if /dev/random on the host (“backend”) blocks?

With havegend and/or jitterentropy-rngd installed on the host, neither /dev/random nor /dev/urandom seem to ever block.

Even without havegend and/or jitterentropy-rngd installed on the host, are inside VM issues, i.e. /dev/random entropy blocking/exhaustion issues ever been reported or reproducible?

If Entropy, Randomness, /dev/random vs /dev/urandom, Entropy Sources, Entropy Gathering Daemons, RDRAND i.e.

/dev/random vs. /dev/urandom

This debate comes from a misconception by the Linux manual writer. […]

is true, then /dev/random vs. /dev/urandom does not really matter and /dev/urandom would be secure either way.

On the other hand Myths about /dev/urandom - Thomas' Digital Garden while “being a strong critic of using /dev/random” still concludes

Linux’s /dev/urandom happily gives you not-so-random numbers before the kernel even had the chance to gather entropy. When is that? At system start, booting the computer.

And I like to add: “When is that? At system start, booting the computer, or when there is a bug.”

It depends on how much entropy KVM reads from the virtio-rng backend and when that is happening. Since there probably never were blocking issues due to use of /dev/random instead of /dev/urandom (?), /dev/random seems better to me.

303

It is recommended in the libvirt manual and is now the default choice for new VMs after backend support was added. The blocking behavior was a big problem.

However, the recommended source of entropy is /dev/urandom (as it doesn’t have the limitations of /dev/random .

In scenarios where a user is running a headless workstation with minimal hardware attached it can be. Some daemons that require entropy can take forever to start if they depend on random.

Both statements are true and there is no contradiction. The only serious difference was during a machine’s early boot. Once started there is no benefit from using random over urandom. Its blocking behavior is sort of a DoS problem where someone can trigger its blocking by drawing entropy in a way that causes it to block. Rate limiting was necessary to stop this but not with urandom.

The difference in practice (random number quality wise) is none because Whonix VMs don’t start early enough in the host boot cycle for it to matter. The blocking action of /dev/random is a performance concern.

It is unlikely most of our users know about jitternetropy to install it on their hosts and so using random over urandom can cause hanging of processes.

1 Like
304

Attempting build, git only shows tags in the version 10 series. Any suggestions what to fix?

305

HulaHoop via Whonix Forum:

Attempting build, git only shows tags in the version 10 series. Any suggestions what to fix?

Upstream git changed the behavior for git tag and others to
scrolling by default (using arrow keys or so). Similar to (GNU) more
command line utility. So just try pressing arrow keys or git --no-pager tag or git tag | cat.

(Btw also systemd supports --no-pager for example sudo systemd status --no-pager. “Pager by default” seems to be a thing nowadays.)

1 Like
306

OK I’ll wait for a new developers point release that includes my latest changes before doing it.

1 Like
307

HulaHoop via Whonix Forum:

OK I’ll wait for a new developers point release that includes my latest changes before doing it.

Not advisable to use developers-only releases, test them and release as
stable:

  • packages might have commits without having bumped version number yet.

Other things unfit for release as of time for writing examples:

308

Is the whonix-libvirt package changes part of 15.0.3.3-stable then?

1 Like
309

No.

Merged in master but not included in any tag.

1 Like
310

Could you review KVM: Difference between revisions - Whonix please?

1 Like
311

Wow what a great cleanup effort. Accepted. Thanks to the author.

1 Like
312

More edits.

KVM: Difference between revisions - Whonix

1 Like
313

Could you please update Whonix ™ for KVM?

This

gpg --keyid-format long --import --import-options show-only --with-fingerprint hulahoop.asc
314

That command would need me to refer to a download link for my key on the Whonix website. I just tested the current keyserver command without problems though, so why is it needed (besides unifying instructions)?

1 Like
315

From my limited experience there can be issues with downloading keys from one day to the next regardless of which keyserver is used. Users should have no issues with downloading hulahoop.asc . If they do, it would also mean they would not be able to download the ova images either . I think the push is to try to find a more reliable and just as secure way to verify whonix images then what is currently available.

Last post on that topic
From: Patrick

Ticket created just now.

stop using gpg keyservers / provide OpenPGP keys for download as files from torproject.org
https://trac.torproject.org/projects/tor/ticket/31090#ticke

2 Likes
316

I see, OK let me know if/where my key is on the site and I’ll change things. In the long term, we can’t afford to ignore the key management infrastrucutre completely becuase that just puts too much trust and availability in one place (our site).

2 Likes
317

For Whonix software downloads? I don’t see any advantage of using keyservers even if they are functional. Users get documentation, software downloads, signatures from whonix.org. So can as well add keys there for completion. Doesn’t improve trust or availability by using keyservers for OpenPGP keys. Well, OpenPGP keys can still be additionally uploaded to keyservers but that’s just a bonus.

For the more general discussion besides Whonix software downloads, see:

318

From what is can see this is the only spot. Although it has both hulahoop.asc and Cli download instructions.

https://www.whonix.org/wiki/KVM#Verify_the_Whonix_.E2.84.A2_Images

1 Like
319

Thanks. Just discovered the wiki blocks .asc uploads.
@Patrick can you please delete my HulaHoop porfile page on the wiki?

EDIT:
KVM instructions updated.

320

Can’t see. Link?