Recurring Time Error within Gateway 11 under VirtualBox 5 - ERROR: Unwanted PVClock kvm-clock tsc acpi_pm detected!

VirtualBox
2

That error doesn’t directly break Tor. It derivatives from the recommend/expected virtualizer configuration.

This is unrelated to UTC. It is about the pvclock setting. If you want more background on it, search the forum for kvmclock. See also Dev/KVM - Whonix. It allows an attack similar to the one described here TimeSync: Whonix ™ Time Synchronization Mechanism.

Did you change any settings in VirtualBox? The paravirtualization providers? Don’t.

This is unsupported, discouraged.
( [unsupported] VirtualBox now supports KVM and Hyper-V as paravirtualization providers )

Whonix 11 didn’t get any updates related to that recently. Did you update from the testers repository?

3

Hi Patrick,

Thanks for your follow-up.

Yes, I always get my updates from the Testers repo.

On Gateway 11 - under System, Acceleration, Paravirtualization interface = Default.

Note, I also have both of these options ENABLED:

Enable VT-x/AMD-v
Enable Nested Paging

I also have 1 CPU allocated with PAE/NX ENABLED

Patrick, also note that even though Paravirtualization interface = Default, the main VBox GUI still reports: KVM Paravirtualization for the Gateway, as it also shows for every linux OS VBox Guest on my system. Are you suggesting changing the setting from Default to None?

Let me know if you can already see the settings choices that are causing this error.

Thanks,

CCP

4

Are we still using these two time related options for the default build? I found them at:

‘https://github.com/Whonix/Whonix/blob/master/build-steps.d/2600_create-vbox-vm’

  1. sudo -u “$user_name” VBoxManage modifyvm “$VMNAME” --rtcuseutc on
  2. sudo -u “$user_name” VBoxManage setextradata “$VMNAME” “VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled” “1”

Neither of the explanations accompanying either option makes either option seem necessary if the host is already set to UTC.

As for the VBox Gateway, under System, Motherboard, users can/should have ‘Hardware Clock in UTC Time’ Checked/Enabled - and also for any other OSes they run where revealing timezones can potentially harm them.

5

Corrupt_Correct_Pig:

Are you suggesting changing the setting from Default to None?

No.

6

Corrupt_Correct_Pig:

Are we still using these two time related options for the default build? I found them at:

https://github.com/Whonix/Whonix/blob/master/build-steps.d/2600_create-vbox-vm

  1. sudo -u “$user_name” VBoxManage modifyvm “$VMNAME” --rtcuseutc on
  2. sudo -u “$user_name” VBoxManage setextradata “$VMNAME” “VBoxInternal/Devices/VMMDev/0/Config/GetHostTimeDisabled” “1”

Still in use. But those are unrelated here. This is not about UTC at
all. This is only related to pvclock.

/sys/devices/system/clocksource/clocksource0/available_clocksource

/sys/devices/system/clocksource/clocksource0/current_clocksource

The stopgap will be a Whonix 12 update to disable this test in VirtualBox.

And if you are wondering about the real fix… The real solution would
be https://phabricator.whonix.org/T437 but unfortunately, it’s very
unlikely to happen. Even fixing this for better supported virtualizers
seems very hard.

Neither of the explanations accompanying either option seems necessary if the host is already set to UTC.

We don’t expect the host to be set to UTC. Also don’t recommend that
anywhere. (Would result in a strange browser fingerprint for
non-torified browsing on the host.) Also would not be great to require
this from users. Luckily UTC here is a non-issue.

As for the VBox Gateway, under System, Motherboard, users can/should have ‘Hardware Clock in UTC Time’ Checked/Enabled - and also for any other OSes they run where revealing timezones can potentially harm them.

This is already advised here:

7

OK Patrick - I’m learning more about this issue as we progress, and I’m glad you’ll work to resolve it in 12.

And, unsurprisingly, the issue of a real fix had crossed my mind. :triumph:

Your UTC explanations make sense in the larger user context.

If it’s important enough to try to isolate the update/group of updates which are triggering this error, I can start with a clean Gateway 11.ova reinstall and a from known set of initial VBox paramaters, and then start running updates/rebooting after each set, and finding out when/where it breaks.

Let me know if you think this is worth the effort.

CCP

8

Corrupt_Correct_Pig:

Let me know if you think this is worth the effort.

No. Wait for the updated whonixcheck repository. No more diagnosis required.

9

Patrick,

Since this whonixcheck ‘error’ does not impact the Gateway’s Tor functionality, it’s not really a significant problem.

I will continue to manually update the Gateway, and wait for a fix.

KUDOS: More generally, you’ve done a great job with Gateway 11! The Gateway runs on my end with excellent stability even with only 128 Mb of allocated DRAM, and even when the Gateway needs to provide an isolated network for several OSes running behind it, concurrently. Furthermore, I see that same Gateway 11 stabilty whether running VBox, or KVM, on my Host.

Just for the record:

From my 64-bit Linux Host:
’# cat /sys/devices/system/clocksource/clocksource0/current_clocksource’
tsc

From the VBoxxed Gateway 11:
’# cat /sys/devices/system/clocksource/clocksource0/current_clocksource’
kvm-clock

Thanks for helping me to understand to what is occuring here Patrick.

CCP

10

The git commit.
https://github.com/Whonix/whonixcheck/commit/cb5f82e20b60b0c70ae73a5e36d53811f17573e9
@HulaHoop please consider testing if kvm-clock detection would still work in KVM.

Still have to produce an upgraded package.

11

Upgrades in testers repository coming soon. (Less than 1 hour expected.)

12

Hi Patrick,

Thank you. I grabbed the update, and whonixcheck is now working correctly on VBox following boot, despite the now understood to be trivial PVClock ‘error’ continuing to be reported.

I think we are making good progress here.

I’ll wait for HulaHoop’s testing/input on the KVM side of the house.

Concerning the whonixcheck process, has the possibility been discussed of having whonixcheck not merely do an apt-get package update check, but to have whonixcheck directly offer to download and install a listed group of upgradeable packages?

This is not a whonixcheck bug, just a potential feature request. In other words, I don’t just want whonixcheck to scan the repos and tell me 24 packages can be upgraded, leaving me to need to apt-get scan the reops again myself, and then download and install the packages. It seems like a waste of time and resources to scan the repos twice for the exact same information.

I think a better/more efficient solution would include:

  1. whonixcheck scans the repos, identifies, and lists all upgradeable packages.
  2. A time test since the last package update check can be used. If a sufficient amount of time has passed since the previous update check, the repo scan should run at every boot.
  3. whonixcheck asks if the user wants to download and install that group of packages (Y/n) from its scan.

Let me know if this functionality has been considered previously, and if it would be difficult, or unwise, to implement.

Cheers,

CCP

13

Corrupt_Correct_Pig:

I grabbed the update, and whonixcheck is now working correctly on
VBox
following boot, despite the now understood to be trivial PVClock ‘error’
continuing to be reported.

Reported as error or warning?

  • Warning → better, that’s the update
  • Error → update did not work

Does whonixcheck still stop?

  • stop → update did not work
  • continue → better, but it should not show a warning anymore

Please post the output of the pvclock this check.

What whonixcheck version you have now installed?

dpkg -l | grep whonixcheck

Should be 3:3.8.2-1.

Concerning the whonixcheck process, has the possibility been
discussed of having whonixcheck not merely do an apt-get package
update check, but to have whonixcheck directly offer to download and
install a listed group of upgradeable packages?

Yes. But it’s too difficult to implement this on the Whonix side. It’s a
Debian [and derivatives] issue. More info:

Upgrading with best security there is left a manual process. Documented
here:

I don’t just want whonixcheck to scan the repos

Every check in whonixcheck can be selectively disabled. For disabling
the operating system updates check, see:

14

Patrick,

Yes - my use of the word ‘error’ was in error. :triumph:

As you can see below, a [WARNING] is generated, and the updates scan is working.

I am running 3:3.8.2-1. The entire run looks like this:

whonixcheck
[INFO] [whonixcheck] Connected to Tor.
[WARNING] [whonixcheck] PVClock Test Result:

Unwanted PVClock kvm-clock tsc acpi_pm detected! Using this PVClock together with Whonix is recommended against, because it conflicts with Whonix’s TimeSync design [1].

If you know what you are doing, feel free to disable this check.
Create a file /etc/whonix.d/50_whonixcheck_user and add:
whonixcheck_skip_functions+=" pvclock_unwanted_detected "

Recommended action:

  • If you are using KVM, you probably did not follow Whonix’s KVM instructions. [2]
  • Or use a different supported Whonix platform. [3]

[1] TimeSync: Whonix ™ Time Synchronization Mechanism
[2] Whonix ™ for KVM
[3] Download Whonix ™ (FREE)
[INFO] [whonixcheck] Whonix is produced independently of, with no guarantee from, The Tor Project. Whonix is experimental software. Do not rely on it for strong anonymity. https://www.whonix.org
[INFO] [whonixcheck] SocksPort Test: Testing Tor’s SocksPort…
[INFO] [whonixcheck] SocksPort Test Result: Connected to Tor. IP: XX.XX.XX.XX
[INFO] [whonixcheck] Whonix News Download: Checking for Whonix news and updates…
[INFO] [whonixcheck] Whonix News Result:
√ Up to date: whonix-gateway-packages-dependencies 2.9-1
√ Up to date: Whonix Build Version: 11.0.0.3.0
[INFO] [whonixcheck] Debian Package Update Check: Checking for software updates via apt-get… ( Documentation: Operating System Software and Updates - Kicksecure )
[INFO] [whonixcheck] Debian Package Update Check Result: No updates found via apt-get.
[INFO] [whonixcheck] Whonix APT Repository: Enabled.
When the Whonix team releases TESTERS updates,
they will be AUTOMATICALLY installed (when you run apt-get dist-upgrade)
along with updated packages from the Debian team. Please
read Placing Trust in Whonix ™ to understand the risk.
If you want to change this, use:
sudo whonix_repository

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

Thanks for your input on ‘automating’ the update download and installation process from within whonixcheck. I understand.

CCP

15

You got the upgrade. But that test doesn’t totally work as expected. It
shouldn’t show that.

Could you please post the output of the following two commands?

sudo virt-what

sudo systemd-detect-virt

16

Patrick,

I’m running KVM atm, so I’ll need to reboot a couple of things to return to VBox.

However, while I here, on an updated Gateway 11 running under KVM, please note this output of whonixcheck, most notably the absence of the PVClock [WARNING].

whonixcheck
[INFO] [whonixcheck] Connected to Tor.
[INFO] [whonixcheck] Whonix is produced independently of, with no guarantee from, The Tor Project. Whonix is experimental software. Do not rely on it for strong anonymity. https://www.whonix.org
[INFO] [whonixcheck] SocksPort Test: Testing Tor’s SocksPort…
[INFO] [whonixcheck] SocksPort Test Result: Connected to Tor. IP: xx.xx.xx.xx
[INFO] [whonixcheck] Whonix News Download: Checking for Whonix news and updates…
[INFO] [whonixcheck] Whonix News Result:
√ Up to date: whonix-gateway-packages-dependencies 2.9-1
√ Up to date: Whonix Build Version: 11.0.0.3.0
[INFO] [whonixcheck] Debian Package Update Check: Checking for software updates via apt-get… ( Documentation: Operating System Software and Updates - Kicksecure )
[INFO] [whonixcheck] Debian Package Update Check Result: No updates found via apt-get.
[INFO] [whonixcheck] Whonix APT Repository: Enabled.
When the Whonix team releases TESTERS updates,
they will be AUTOMATICALLY installed (when you run apt-get dist-upgrade)
along with updated packages from the Debian team. Please
read Placing Trust in Whonix ™ to understand the risk.
If you want to change this, use:
sudo whonix_repository

Also, while I’m running KVM, here is the Gateway 11 output you requested:

sudo virt-what
kvm

sudo systemd-detect-virt
kvm

I’ll post the Gateway output from within VBox in a few minutes.

CCP

17

Patrick,

This is the Gateway output while it is running under VBox:

sudo virt-what
virtualbox
kvm

sudo systemd-detect-virt
kvm

As I mentioned earlier, Acceleration is set to Default for my Gateway in VBox.

CCP

18

The user support answer would be:
Good enough for now. Might be fixed in Whonix 13. Don’t hold your breath for it.

Since you seem to be interested in the technical backgrounds, this will be the development discussion answer:
I keep it in the same topic, since otherwise this does not get attention anyhow, and I wouldn’t know who else would look into Whonix VirtualBox development.

Your Whonix KVM [real KVM on LInux, I suppose] results seems fine.

The terminology now gets difficult since VirtualBox 5 now also supports KVM as paravirtualization provider. ( [unsupported] VirtualBox now supports KVM and Hyper-V as paravirtualization providers)

Your Whonix VirtualBox results are not ideal development wise yet. The problem now is, that systemd-detect-virt detects kvm, even though you are running in VirtualBox.

I am wondering why you are the only one reporting this. Did you change System, Acceleration, Paravirtualization interface?

FYI, it’s related to:

If you set it to Paravirtualization interface to legacy, that whonixcheck error should varnish. Also the output of cat /sys/devices/system/clocksource/clocksource0/available_clocksource should change then.

I wonder what the optimal paravirtualization for Whonix 13 will be.

  • default is problematic, since as in your case, it does autodetection, then used VirtualBox KVM

  • 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.

  • Does not seem like pvclocks can be configured in VirtualBox. (With linux libvirt kvm it’s possible.)

  • TimeSync: Whonix ™ Time Synchronization Mechanism

  • However, this presupposes that users did read and apply Advanced Security Guide - Whonix beforehand, which probably few do.

  • Therefore probably not a big issues.

  • 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 ( Protocol Leak and Fingerprinting Protection‎ ).

Not sure you noticed the new Download table yet:

The point is, it introduces a security column. For your information:

19

Hi Patrick,

Yes - I’ve got Gateway 12 updated and running. I can confirm the entire PVClock issue on VBox stems from the paravirtualization choice. I knew this before I even saw your latest, because I noticed you had Legacy selected as the default VBox Acceleration on 12.

I ran whonixcheck both ways: Legacy and Default.

With Legacy, no PVClock [WARNING] and apt-get scan completes.

With Default, the PVClock [WARNING] is present and apt-get scan completes.

And yes, it does appear that VBox ‘auto-selects’ KVM paravirtualization for Linux Guests running on Linux Hosts when Acceleration = Default is selected.

I think we’ve beaten this issue to death, but at least we understand what is driving it. It certainly is not an issue worth losing sleep over, as the Gateway continues to operate correctly in either acceleration mode.

Thanks for all your support Patrick,

CCP - an almost normally-adjusted, non-breath-holder :triumph:

20

The remaining question is, which setting the best VirtualBox paravirtualization setting for Whonix is.

21

Hi Patrick,

Yes, I did note the new Security tab. I do realize you face limited time and resources, yet it is unfortunate Whonix does not have a dedicated VBox maintainer. I say this because the VBox user base is likely much larger than the combined number of KVM and Qubes users, by a significant factor. I also doubt this VBox user base disparity is likely to change any time soon.

I am pretty sure a new VBox topic such as ‘Whonix VBox Paravirtualization - Which Acceleration Mode is Optimal? Help Us Test!’ is warranted at this point.

I do not want to presume which testing information would prove the most useful for you to make a VBox determination.

However, I imagine you would want VBox users to report:

  1. Host OS name: Win 10, Gentoo, etc.
  2. Host OS architecture: 64 or 32 Bit
  3. Gateway Version - only 11, or better.
  4. VBox Acceleration Mode Used
  5. Notable Observations - errors, warnings. slowness, failures, etc.
  6. Any other ‘things’ you deem important.

It is probably best to create a short form that users can fill out with the requested information so you don’t have to hunt through long text ‘essays.’

Once the Gateway performance is understood across a range of systems, then you could open testing up for the Workstation, if desired.

To close, another loop, I am now running Gateway 11 under Acceleration = None.

No errors, no warnings, and apt-get works. However, just after the apt-get scan began, the Gateway reported:

hrtimer: interrupt took xxx ns

I don’t know if that is significant, or not.

In any event, the Gateway is operating correctly under Acceleration = None, and if any ‘slowness’ is in fact occurring, it is imperceptible. Perhaps there is some kind of relevant speed test?

Food for thought.

CCP