[HOME] [DOWNLOAD] [DOCS] [BLOG] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Whonix VirtualBox Paravirtualization - Which Acceleration Mode is Optimal? Help Wanted!


#1

Originally published at: https://www.whonix.org/blog/virtualbox-acceleration-mode
What will be the optimal paravirtualization setting for Whonix?

  • none explicitly turns off exposing any paravirtualization interface sounds good security wise but could be really slow. Please test and leave feedback.
  • minimal sounds like a worthwhile alternative if `none` is too slow. But what technology is `minimal` actually using? VirtualBox legacy or kvm? However, documentation says, it lets the VM read the APIC frequency. To be researched how bad this would be.
  • legacy is good enough for now. That's like VirtualBox 4.x. But since they now call it legacy, that code will rot, and probably should be avoided in long run.
  • kvm (VirtualBox) is problematic, since it provides unwanted pvclock kvm-clock. (Which allows a clock correlation attacks once VM is compromised.
  • default is problematic, since in some cases, it does autodetection, then used VirtualBox KVM.
  • hyperv The microsoft thingy. No idea about that one. May or may not be great for Linux guests (Whonix).
Each virtualization platform should be reviewed for performance, security, pvclock interfaces and hardware identifiers readable by the vm.

Please try various settings. Most interesting for now are none and minimal. Post the following in the forum discussion thread on this topic.

  1. Host OS name: Debian, Windows 10, Gentoo, etc.
  2. Host OS architecture: 64 or 32 Bit
  3. Whonix Version - only 11, or better.
  4. VirtualBox Version used - only VirtualBox, or better
  5. VirtualBox Acceleration Mode Used
  6. Notable Observations - errors, warnings. slowness, failures, etc.
  7. Does watching online videos such as youtube still work?
  8. Does watching videos in VLC still work?
  9. Open a console window. Post the output of. cat /sys/devices/system/clocksource/clocksource0/current_clocksource
  10. And the output of. cat /sys/devices/system/clocksource/clocksource0/available_clocksource
  11. Any other 'things' you deem important.
This is related to:  

Recurring Time Error within Gateway 11 under VirtualBox 5 - ERROR: Unwanted PVClock kvm-clock tsc acpi_pm detected!
Recurring Time Error within Gateway 11 under VirtualBox 5 - ERROR: Unwanted PVClock kvm-clock tsc acpi_pm detected!
Hyper-V and Whonix?
Recurring Time Error within Gateway 11 under VirtualBox 5 - ERROR: Unwanted PVClock kvm-clock tsc acpi_pm detected!
#2

#3

Hi Patrick,

Additional Paravirtualization Interface multimedia testing to drive this issue to a conclusion.

64-Bit Linux Host running VBox 5.0.10 and running a fully updated Whonix Gateway 11 with
128 Mb allocated DRAM as one of the Guest operating systems

Test 1: Running these two Guests concurrently:

Gateway 11 Paravirtualization Interface = None
Whonix Workstation 11 Paravirtualization Interface = None

Notable Results:

In the Gateway: Notable Observations: whonixcheck works, and the Gateway operates
correctly. I suspect the hrtimer interrupt issue is an anomaly, as I have now seen it reported when whonixcheck is not running. Does not appear to impact anything.

In the Workstation: whonixcheck works, YouTube works, and VLC works - and everything works correctly at ‘normal’ speeds.

+++++++++++++++++++++++++++++++++++++++++++++++++++

Test 2: Running these two Guests concurrently:

Gateway 11 Paravirtualization Interface = None
A 64-Bit Linux Guest OS pointed at the Gateway with Paravirtualization Interface = None

Notable Results:

In the Gateway: Notable Observations: whonixcheck works, and the Gateway operates
correctly.

In the 64-Bit Linux Guest OS: YouTube works, and VLC works - and everything works correctly at ‘normal’ speeds.

+++++++++++++++++++++++++++++++++++++++++++++++++++

These results show, at least on my system, that even with both the Gateway and the other Guest OS using Paravirtualization Interface = None, the overall Whonix user ‘experience’ remains within an acceptable range.

Perhaps this configuration is not optimal, but it is indeed, acceptable. :triumph:

CCP


#4

Multimedia. Does watching online videos (youtube) still work? Does watching videos in VLC still work?


#5

Hi Patrick,

I do not have time at the moment to go back and test multimedia support under: None. Perhaps later.

Here is what I do know:

My Paravirtualization Interface test results:

All tests were run on a fully updated RPM-based, 64-Bit, Host running VBox 5.0.10 and running a fully updated Whonix Gateway 11 with 128 Mb allocated DRAM as one of the Guest operating systems.

  1. Paravirtualization Interface = Default
    Notable Observations: PVClock warning as reported above. whonixcheck works, and the Gateway operates correctly.

  2. Paravirtualization Interface = KVM
    Notable Observations: Exact same results as #1 above as KVM acceleration is the VBox default for Linux guests.

  3. Paravirtualization Interface = None
    Notable Observations: whonixcheck works, and the Gateway operates correctly. I noted the ‘hrtimer: interrupt took xxx ns’ issue previously when using this mode.

  4. Paravirtualization Interface = Minimal
    Notable Observations: whonixcheck works, and the Gateway operates correctly.

  5. Paravirtualization Interface = Legacy
    Notable Observations: whonixcheck works, and the Gateway operates correctly.

  6. Paravirtualization Interface = Hyper-V (which is aimed at Windows guests)
    Notable Observations: whonixcheck works, and the Gateway operates correctly.

My take on this data is that the Gateway utilizes almost trivial Host resources, and that is the reason almost no differences are evident irrespective of the Paravirtualization Interface chosen.

I would not be surprised if much larger differences were observed when testing different Paravirtualization Interfaces running full blown operating systems with KDE or Gnome or Cortana running behind the Gateway, such as the Whonix Workstation, Win 10, or Arch Linux.

However, even if that were true, I suspect you would need to have several, if not many, different Host systems, in your test database to draw any valid conclusions concerning which VBox Paravirtualization Interface is the best overall choice for Workstation OS guests.

Keep in mind, the correct answer may be: it depends, and therefore, it is up to the user to experiment and decide for themselves.

CCP


#6

From my search I concluded, “if everything is working, then everything is fine”. I also think it’s unrelated. This message has been posted in the forums earlier.


#7

https://packages.debian.org/stretch-backports/virtualbox ships VirtualBox 5.1.30, which no longer has gui settings for paravirtualization providers. It defaults to KVM.


VirtualBox manual doesn’t list most options anymore.

https://www.virtualbox.org/manual/ch10.html#gimproviders

Minimal: Announces the presence of a virtualized environment. Additionally, reports the TSC and APIC frequency to the guest operating system. This provider is mandatory for running any Mac OS X guests.

KVM: Presents a Linux KVM hypervisor interface which is recognized by Linux kernels starting with version 2.6.25. VirtualBox’s implementation currently supports paravirtualized clocks and SMP spinlocks. This provider is recommended for Linux guests.

Hyper-V: Presents a Microsoft Hyper-V hypervisor interface which is recognized by Windows 7 and newer operating systems. VirtualBox’s implementation currently supports paravirtualized clocks, APIC frequency reporting, guest debugging, guest crash reporting and relaxed timer checks. This provider is recommended for Windows guests.


https://www.virtualbox.org/manual/ch08.html#idp47569025503568

–paravirtprovider none|default|legacy|minimal|hyperv|kvm: This setting specifies which paravirtualization interface to provide to the guest operating system. Specifying none explicitly turns off exposing any paravirtualization interface. The option default, will pick an appropriate interface depending on the guest OS type while starting the VM. This is the default option chosen while creating new VMs. The legacy option is chosen for VMs which were created with older VirtualBox versions and will pick a paravirtualization interface while starting the VM with VirtualBox 5.0 and newer. The minimal provider is mandatory for Mac OS X guests, while kvm and hyperv are recommended for Linux and Windows guests respectively. These options are explained in detail under Section 10.4, “Paravirtualization providers”.

Dunno if the latter is still up to date. Perhaps none was removed?

So this still needs research which one is best.


#8

#9

Minimal: Announces the presence of a virtualized environment. Additionally, reports the TSC and APIC frequency to the guest operating system. This provider is mandatory for running any Mac OS X guests.

This indicates none doesn’t provide TSC. However, TSC is required by haveged.


#10

perhaps i am misreading you, @Patrick. but, in the gui manager for virtualbox 5.1.30 through stretch-backports, there is a pull down menu to select a paravirtualization provider. click on “settings” for the vm in question. then click “system -> acceleration.” there is a gui option to choose providers next to “paravirtualization interface.” current stable whonix defaults to “legacy.”


#11

tempest:

perhaps i am misreading you, @Patrick. but, in the gui manager for virtualbox 5.1.30 through stretch-backports, there is a pull down menu to select a paravirtualization provider. click on “settings” for the vm in question. then click “system -> acceleration.” there is a gui option to choose providers next to “paravirtualization interface.” current stable whonix defaults to “legacy.”

Right.

My mistake. Was happening for me since there was no VT-X available.

For Whonix 14 as per VirtualBox it currently defaults to “default”,
which is KVM.

Still debatable which one is best.